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ABSTRACT 


The  micro-mainframe  issue  has  rocketed  to  prominence,  fueled  by  the  profusion  of 
vendor  product  announcements  and  an  explosive  end-user  demand.  There  is  a  real 
danger,  however,  that  the  issues  united  under  the  banner  of  "micro-mainframe"  could 
produce  a  discontinuity  in  data  processing  at  least  as  large  as  that  produced  by  the 
introduction  of  the  System/360. 

This  report  addresses  the  components  of  the  micro-mainframe  phenomenon.  The 
directions  of  end  users  are  explored  through  five  case  studies.  The  future  oirections 
of  micro-mainframe  products  are  investigated,  and  the  major  technological  and 
planning  issues  are  identified.  Recommendations  that  focus  on  the  technical,  end- 
user,  and  vendor  aspects  of  micro-mainframe  needs  are  also  included. 

This  report  contains  158  pages,  including  52  exhibits. 
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INTRODUCTION 


BACKGROUND 

The  micro-mainframe  issue  is  one  that  scored  high  in  INPUT'S  1983  client 
poll.  Since  then,  interest  has  continued  to  climb,  assisted  by  a  barrage  of 
vendor  announcements. 

However,  the  profusion  of  announcements  of  products  (and  some  pseudo- 
products)  has  made  it  in  some  ways  more  difficult  to  identify  and  understand 
the  real  issues.  Most  current  vendor  products  and  corporate  plans  are  pre- 
liminary, where  they  are  not  primitive. 

INPUT  believes  that  the  group  of  issues  united  under  the  banner  "micro-main- 
frame" could  produce  a  discontinuity  in  data  processing  at  least  as  large  as 
that  produced  by  the  introduction  of  the  System/360.  With  this  view,  the 
micro-mainframe  question  becomes  much  more  than  a  question  of,  for 
example,  screen  versus  file  transfer. 

INPUT  intends  that  the  studies  contained  in  this  series  of  reports  (see  section 
C  of  this  chapter)  be  useful  planning  documents  over  a  three-  to  five-year 
planning  horizon,  although  the  reports  do  not  neglect  current  issues  or  tech- 
nical detail. 
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•  The  study  generally  assumes  that  the  micro-mainframe  world  is  an  IBM  world 
(or  an  IBM-compatible  world,  which  in  many  ways  is  the  same  thing).  This  has 
obviously  been  true  for  some  time  at  the  mainframe  level  and  the  issue  will 
not  be  belabored  here. 


At  the  micro  level  this  assumption  is  still  somewhat  debatable;  for 
example,  Apple's  Macintosh  and  ATT's  recently  announced  computer 
series  may  still  provide  a  basis  for  corporate  micro-mainframe 
strategies.  However,  two  key  points  should  be  made: 

IBM's  current  interconnect  strategy  will  provide  an  underlying 
environment  for  Information  Systems  (IS),  end  users,  and 
vendors,  as  shown  in  Exhibit  I- 1. 

Equally  important  is  the  view  held  by  IS  departments.  The  non- 
IBM-compatible  share  of  corporate  micros  is  expected  by  IS 
management  to  be  very  low  compared  to  IBM  and  IBM-com- 
patibles, as  shown  in  Exhibit  1-2. 

This  does  not  mean  that  there  is  not  and  will  not  be  a  place  for  innova- 
tive micro  hardware  in  large  enterprises.  However,  from  the  stand- 
point of  micro-mainframe  connectivity,  such  devices  will  have  to  look 
like  comparable  IBM-compatible  equipment  in  order  to  be  easily  used 
and  accepted;  or  at  least  they  must  be  transparent  to  IBM  networks. 

B,  METHODOLOGY 

•  The  research  for  this  report  was  conducted  in  parallel  with  that  for  three 
related  reports  (see  next  section).  A  large  project  team  spent  over  four 
months  researching  and  analyzing  information  in  this  rapidly  changing  area. 
The  research  consisted  of  the  following  major  activities: 
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EXHIBIT  1-1 
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EXHIBIT  1-2 
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Client  interviews. 

Corporate  interviews,  case  studies,  and  consulting. 
Vendor  interviews,  case  studies,  and  consulting. 
Product  and  service  analyses. 
Client  interviews. 

INPUT  clients  were  sannpled  in  December  and  January  to  ascertain 
their  areas  of  special  interest  and  to  learn  of  their  experiences, 
problenns,  and  needs. 

Corporate  interviews. 

Seventy-eight  structured  interviews  were  conducted  with  IS  nnanage- 
ment  at  large  companies  in  February  and  March  of  1984. 

The  questionnaire  used  is  in  Appendix  A.  . 

Company  sizes  and  industries  are  shown  in  Appendix  B. 

These  interviews  were  unusual,  owing  to  the  fact  that  they  were  much 
longer  than  typical  interviews  (i.e.,  averaging  45  minutes  to  over  an 
hour);  respondents  were  highly  motivated  and  forthcoming. 

In  addition,  INPUT  had  the  opportunity  to  review  over  20  companies  in 
depth.  Some  of  the  experiences  of  these  companies  are  described  in 
the  reports  in  detail;  other  information  was  used  to  inform  our  analysis 

and  recommendations. 
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In  the  past  nine  months,  INPUT  has  conducted  a  number  of  consulting 
studies  that  bear  on  the  micro-mainframe  issue.  Five  of  these  studies 
have  specifically  addressed  micro-mainframe  issues  from  the  corporate 
standpoint,  and  the  knowledge  gained  is  relayed  in  this  report. 

Vendor  interviews. 

Structured  interviews  were  conducted  with  vendor  personnel  from  20 
companies  in  February  and  March.  The  questionnaire  used  is  shown  in 
Appendix  C. 

In  addition,  more  than  30  other  people  from  vendor  organizations  were 
interviewed  in  particular  issue  areas. 

Vendors,  too,  were  highly  interested  in  the  topic  and  were  quite  forth- 
coming. A  number  of  interviews  were  multihour  in  length.  Those 
interviewed  ranged  from  senior  technical  staff  to  company  presidents. 
The  companies  included  small,  innovative  software  firms  and  very  large 
hardware  companies. 

INPUT'S  recent  consulting  studies  have  included  four  that  address 
vendor  micro-mainframe  issues.  Although  no  proprietary  information 
from  these  engagements  was  used  directly  for  these  public  studies, 
these  engagements  provided  INPUT  with  an  in-depth  sensitivity  to 
vendor  requirements. 

Product  and  service  analysis. 

INPUT  has  collected  and  analyzed  information  on  several  hundred 
products  and  services  in  the  micro-mainframe  area. 

Unfortunately,  some  of  the  information  obtained  at  the  beginning  of 
the  study  is  already  obsolete.  INPUT  estimates  that  micro-mainframe 
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technical  and  product  infornnation  has  a  half-life  of  about  six  nnonths. 
Several  products  will  probably  be  formally  available  a  short  time  after 
the  release  of  this  report.  The  rate  of  new  product  introduction  has 
been  very  high,  and  INPUT  expects  it  to  continue;  for  example,  there 
are  high-speed  micro-mainframe  links  from  LAN  vendors,  and  Cullinet 
has  a  micro-mainframe  intelligent  link. 

in  general,  micro-mainframe  products  are  evolving  very  quickly. 
Consequently,  extensive  detailed  product  comparisons  will  soon  be  out 
of  date. 

Therefore,  INPUT  has  used  specific  products  largely  to  illustrate  more 
basic  issues.  INPUT'S  goal  has  been  to  make  this  a  study  that  would 
require  only  marginal  updating  for  it  to  remain  a  useful  planning  tool  a 
year  from  now. 

•  Some  of  the  survey's  quantitative  results  would  have  appeared  surprising,  even 
dubious,  to  the  INPUT  micro-mainframe  project  team  had  it  not  been  for 
other  micro-mainframe-related  studies  that  INPUT  has  conducted  in  the  past 
six  months. 

Several  of  these  other  studies  included  in-depth  (i.e.,  one  to  two  hours), 
face-to-face  interviews  conducted  with: 

Over  50  IS  managers  and  planners. 

Over  25  people  in  end-user  management  (up  to  the  executive 
vice  president  level  in  multibillion-dollar  organizations). 

These  other  studies  are  very  supportive  of  the  projections  contained 
here  and,  from  the  standpoint  of  end-user  motivations  and  plans,  may 
even  go  beyond  some  of  the  findings  here. 
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•  Although  the  companies  interviewed  for  this  report  were  selected  randonnly, 
in  a  sense  the  respondents  were  not.  But  respondent  self-selection  has  worked 
to  the  study's  benefit,  in  INPUT'S  opinion. 

Respondents  were  in  IS  executive  or  planning  management,  and  the  job 
titles  have  the  usual  distribution  for  this  type  of  study. 

However,  in  arranging  interviews,  INPUT  was  usually  (and  properly) 
directed  to  the  person  that  was  most  knowledgeable  on  micro-main- 
frame issues  in  that  organization. 

This  person  was  almost  always  ahead  of  the  rest  of  the  organization  in 
information  and,  more  importantly,  in  insight.  These  respondents  often 
know  where  their  IS  organizations  are  going  before  most  others  in  the 
organization  have  even  begun  to  consider  the  issues. 

Fortunately,  this  brings  the  results  of  the  survey  much  more  in  synch 
with  end-user  directions  and  motivation.  (For  obvious  reasons,  it  is 
very  important  to  understand  where  end  users  are  going.) 

C.      OTHER  RELATED  INPUT  REPORTS 

•  This  report  is  being  issued  in  conjunction  with  three  other  reports  in  the 
micro-mainframe  series  of  reports,  as  shown  in  Exhibit  1-3.  These  reports  are: 

Micro-Mainframe:  Communications  Issues 

This  report  is  part  of  the  Information  System  Program  (ISP)  that 
Is  utilized  by  IS  management. 
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•  This  study  addresses  current  developments  as  well  as  future 
trends  In  nr>lcro-mainframe  connmunications. 

The  micro  promises  to  have  a  significant  impact  on  communica- 
tions. This  report  analyzes  positive  and  negative  effects  of 
these  changes  and  provides  strategies  for  dealing  with  them. 

Micro-Mainframe;  Personal  Computer  Impacts  , 

This  report  is  part  of  the  Market  Analysis  and  Planning  Service 
(MAPS)  that  is  utilized  by  information  service  vendors. 

The  study  addresses  and  analyzes  micro-mainframe  develop- 
ments and  the  impact  they  will  have  on  the  personal  computer 
industry. 

•  The  report  provides  market  forecasts  and  strategies  for  taking 
advantage  of  coming  structural  changes. 

Micro-Mainframe;  Processing  and  Turnkey  Strategies 

This  report  is  part  of  the  Market  Analysis  and  Planning  Service 
(MAPS)  program  that  is  utilized  by  information  service  vendors. 

.  This  study  analyzes  micro-mainframe  developments  from  the 
standpoint  of  their  effect  on  traditional  RCS  and  turnkey 
services. 

•  The  report  provides  market  forecasts  and  strategies  for  adapting 
to  a  rapidly  changing  set  of  customer  needs. 

•        These  four  reports  share  a  common  core  of  concepts,  and  data  is  presented  to 
readers  in  the  following  way; 
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The  reports  avoid  (when  possible)  referring  readers  to  pertinent 
sections  of  other  reports,  in  order  to  make  each  report  stand  on  its 
own. 

Data  analyses  or  concepts  that  are  discussed  in  more  detail  in  other 
reports  are  summarized. 

Detailed  information  is  included  in  appendices, 
related  INPUT  reports  include: 

Selecting  User  Friendly  Operating  Systems  for  Personal  Computers, 
June  1983. 

Executive  Workstation  Acceptance:  Problems  and  Outlook,  May  1984. 
Organizing  the  Information  Center,  August  1 983. 
Supporting  Personal  Computer  Software,  August  1 983. 
Data  Administration:  Experiences  and  Outlook,  June  1 984. 
Personal  Computers  in  the  I.S.  Strategy,  December  1 982. 
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EXECUTIVE  SUMMARY 


\ 


EXECUTIVE  SUMAAARY 


This  executive  summary  is  designed  in  a  presentation  format  in  order  to: 

Help  the  busy  reader  quickly  review  key  research  findings. 

Provide  an  executive  presentation  and  script  that  facilitates  group 
communications. 

The  key  points  of  the  entire  report  are  summarized  in  Exhibits  11- 1  through  II- 
7.  On  the  left-hand  page  facing  each  exhibit  is  a  script  explaining  the 
exhibit's  contents. 
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END-USER  AND  \S.  MANAGEMENT  VIEWS  OF  THE  MICRO 


•  Micros  were  viewed  quite  differently  by  end  users  and  IS  managers  when  they 
first  began  to  appear  on  the  corporate  scene. 

•  End  users  saw  the  personal  computer  (PC)  as  a  great  breakthrough  that 
allowed  them  to  take  charge  of  considerable  amounts  of  their  data  processing 
destiny.  The  PC  was: 

Responsive:  Jobs  could  be  accomplished  literally  overnight  without 
being  filtered  through  intermediaries. 

Flexible:  Users  were  not  locked  into  a  particular  approach  but  could 
build  what  were,  in  reality,  prototypes. 

Self-directed:  Perhaps  most  important  was  being  able  to  directly 
integrate  and  control  data  processing  support. 

•  Even  the  Information  Center  (which  did  not  exist  at  that  time  in  many  organi- 
zations) could  not  provide  this  kind  of  control. 

•  Many  IS  managers  were  unaware  of  the  micro  phenomenon.  Others  did 
nothing,  and  some  viewed  the  micro  as  a  threat  to  orderly  data  processing. 

•  Toward  the  end  of  the  early  micro  period,  many  IS  departments  recognized 
the  micro  and  took  steps  to  control,  or  at  least  to  coordinate,  its  use. 

•  Most  IS  managers  agree  that  their  PC  actions  have  been  reactive  and  have 
generally  not  been  a  major  influence  on  the  amount  or  extent  of  end-user  PC 
use. 
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EXHIBIT  11-1 


END-USER  AND  LS.  MANAGEMENT 
VIEWS  OF  THE  MICRO  (1981) 
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END-USER  AND  1^.  MANAGEMENT  VIEWS  OF  MICRO-MAINFRAME 


LINKAGE 


•  History  may  be  about  to  repeat  itself  with  regard  to  micro-mainframe 
linkage.  However,  there  are  much  greater  dangers  from  missteps  in  handling 
micro-mainframe  issues,  largely  because  end  users  and  IS  must  work  well  and 
closely  together  if  micro-mainframe  efforts  are  to  be  successful. 

•  Most  IS  departments  still  see  the  micro-mainframe  issue  as  business  as  usual. 
Looking  at  the  situation  from  IS's  standpoint,  control  (i.e.,  restriction  of 
access)  becomes  more  important  so  that  end  users  do  not  disrupt  the  opera- 
tional system.  Consistent  with  control,  data  generally  flows  downward, 
usually  from  file  extracts.  IS  implicitly  assumes  that  this  data  will  generally 
be  put  to  analytic  use.  That  is,  the  next  generation  in  connectivity  will  be 
supporting  the  next  generation  of  spreadsheets. 

•  There  is  much  to  be  said  for  this  viewpoint,  since  this  is  the  sort  of  activity 
that  current  vendor  products  are  supporting.  Also,  most  end  users  with  some 
kind  of  micro-mainframe  linkage  are  generally  using  downloaded  data  for 
analysis. 

•  However,  INPUT'S  research  and  analysis  strongly  indicate  that  the  picture  is 
already  very  different  in  the  minds  of  many  end  users.  They  see  micro-main- 
frame links  as  providing  not  just  the  relatively  limited  self-direction  they 
have  with  standalone  micros,  but  also  the  potential  for  much  greater  self- 
determination.  This  means  having  two-way  data  flow. 

Not  surprisingly,  given  this  view,  users  will  increasingly  be  viewing 
operational  and  analytic  use  interchangeably. 


-  16- 

©  1984  by  INPUT.  Reproduction  Prohibited. 


INF 


EXHIBIT  II-2 


END-USER  AND  I.S.  MANAGEMENT  VIEWS 
OF  MICRO-MAINFRAME  LINKAGE  (1984) 
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C.       MiCRO-MAINFRAME  APPLICATIONS  GROWTH;  1984-1988 


•  INPUT  forecasts  that  by  1988  about  a  quarter  of  installed  mainframe  applica- 
tions will  be  micro-mainframe  applications. 

The  potential  range  is  from  20%  to  35%. 

In  type  and  complexity,  these  applications  will  be  representative  of 
today's  host  applications;  hence  these  figures  generally  will  be  repre- 
sentative of  processing  requirements  as  well. 

Projections  were  based  on  INPUT'S  assessment  of  the  likelihood  of 
implementation  plans  being  achieved  and  the  attitudes  toward  micro- 
mainframe applications  on  the  part  of  the  corporations  interviewed. 

•  This  level  of  growth  means  that  data  processing  systems  will  look  far 
different  in  five  years.  Planners  must  prepare  their  IS  organizations  for  great 
changes.  These  changes  will  have  significant  impact  on: 

The  technical  nature  of  systems. 

The  IS  organization  and  IS  relations  with  end  users. 

In  many  cases,  the  way  in  which  a  corporation  conducts  its  business. 

•  Before  examining  these  impacts,  two  key  attributes  of  "micro-mainframe 
applications"  should  be  examined  further.  These  are: 

Shared  functionality. 

Connectivity  alternatives. 
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EXHIBIT  11-3 


MICRO-MAINFRAME 
APPLICATIONS  GROWTH:  1984-1988 
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D.      SHARED  FUNCTIONALITY:  THE  GOAL  AND  THE  CHALLENGE 


•  INPUT  has  coined  the  term  "shared  functionality"  to  describe  nnicro-main- 
frame  applications  where  a  data  processing  activity  cannot  be  carried  out 
without  processing  and/or  data  being  shared  by  both  the  mainframe  and  micro. 

•  This  view  of  shared  functionality  is  held  by  85%  of  INPUT'S  respondents  when 
referring  to  "micro-mainframe  applications." 

•  Even  more  important  is  the  fact  that  three-quarters  of  respondents  see  most 
applications  that  are  now  host-based  as  having  this  kind  of  shared  func- 
tionality in  three  to  five  years. 

•  Shared  functionality  promises  revolutionary  changes  for  computer  systems  and 
their  implementation. 

•  Although  most  end  users  do  not  express  themselves  in  technical  language, 
when  they  are  presented  with  this  kind  of  diagram  illustrating  shared  func- 
tionality, they  say,  "Of  course  this  is  what  we  want." 

•  There  are  serious  technical  issues  to  be  overcome,  however.  These  are  dis- 
cussed in  the  next  two  sections. 
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EXHIBIT  II-4 

SHARED  FUNCTrONALITY: 
THE  GOAL  AND  THE  CHALLENGE 
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E.      CONNECTIVITY  ALTERNATIVES 


•  The  interactive  approach  to  connectivity  is  virtually  Impossible  to  achieve, 
given  today's  technical  constraints. 

In  spite  of  that,  three-quarters  of  INPUT'S  survey  respondents  believe 
the  interactive  mode  will  be  used  at  least  half  the  time.  / 

It  should  be  stressed  that  these  were  informed  IS  planners  and 
managers,  so  obviously  they  were  looking  beyond  what  exists  now,  to 
what  will— or  should— exist  in  the  future. 

•  In  the  short  run,  only  on-line  batch  systems  will  be  feasible.  However,  on-line 
batch  applications  will  often  appear  to  end  users  as  being  virtually  inter- 
active. The  key  issue  is  whether  some  of  the  micro-accessed  data  must  be 
identical  to  that  at  the  host  level  or  whether  data  that  is  periodically  re- 
freshed will  serve  just  as  well. 

This  is  a  key  issue  and  should  be  the  foundation  of  all  micro-mainframe 
data  analysis.  This  distinction  has  not  had  to  be  made  for  most  current 
interactive  systems,  since  the  choices  are  generally  between  totally 
on-line  or  classical  batch  implementations. 

Micro-mainframe  systems  will  Introduce  an  intermediate  class  of  data 
and  data  analysis. 

In  the  long  run,  when  true  interactive  systems  are  possible,  they  may 
well  make  use  of  such  resource-hungry  tools  as  relational  data  bases. 
Consequently,  the  on-line  batch  approach  will  always  have  efficiency 
attractions.  In  addition,  on-line  batch  applications  will  be  easier  to 
design  and  construct  since  many  good  design  concepts  such  as  re- 
stricted entry  and  exit  points  in  modules  will  be  enforced  by  the 
physical  separation  of  devices. 
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EXHIBIT  11-5 


CONNECTIVITY  ALTERNATIVES 
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F.       MICRO-MAINFRAME  DANGERS 


•  The  danger  of  attempting  interactive  micro-mainframe  applications  pre- 
maturely has  already  been  described.  There  are  other  large  dangers  in  micro- 
mainframe applications,  especially  those  that  are  poorly  thought  through. 

Linking  data  across  applications  will  become  Increasingly  difficult  if, 
as  expected,  local  micro  users  will  modify  their  data  structures  to  best 
meet  their  local  needs. 

Security  is  something  that  even  mainframe  applications  often  only  pay 
lip  service  to,  depending  excessively  on  whatever  is  built  into  applica- 
tions packages  or  supplied  in  access  control  packages.  Both  physical 
security  and  data  synchronization  problems  will  develop  new  dimen- 
sions in  a  micro-mainframe  environment. 

Micro  systems  are  noted  for  their  flexibility.  But  by  becoming  con- 
nected to  host -based  systems  they  must  give  up  at  least  part  of  this 
flexibility;  the  goal  of  designers  will  be  to  make  this  loss  as  small  as 
possible. 

Similarly,  in  a  micro-mainframe  application,  neither  the  end  user  nor  IS 
will  have  sole  control.  This  can  be  disastrous  where  the  two  groups 
have  different  priorities  or  have  not  learned  how  to  work  together. 

•  A  hidden  danger  is  that  current  design  and  implementation  policies  usually 
will  become  obsolete  or  obsolescent  in  a  micro-mainframe  environment. 
Unfortunately,  each  IS  group  (for  the  time  being)  will  have  to  devise  a  satis- 
factory methodology  for  itself. 
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EXHIBIT  11-6 

MICRO-MAINFRAME  DANGERS 

•  Data  Base  Linkages 

•  Security 
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G.  RECOMMENDATIONS 


•  Users  should  be  educated  on  IS  technology  and  issues.  A  general  confidence- 
building  strategy  is  also  needed.  This  strategy  may  include:  regular, 
informed,  face-to-face  meetings  between  IS  management  and  its  peers;  a 
frankness  in  admitting  IS  problems  and  deficiencies;  and  objective  ratings  of 
IS  performance. 

•  IS  should  take  steps  to  gain  a  deeper  understanding  of  the  company's  (and 
individual  department's)  key  business  goals,  motivations,  and  problems. 

•  The  IS  PC  support  unit  should  be  expanded  to  include  all  the  functions  outlined 
in  INPUT'S  report,  Supporting  Personal  Computer  Software,  August  1983.  This 
is  the  most  effective  means  for  creating  a  deep  understanding  of  micro  oppor- 
tunities and  limitations. 

•  IS  should  initiate  low-risk  micro-mainframe  projects  as  a  learning  tool  and  a 
confidence  builder. 

•  Micro-mainframe  initiatives  may  accelerate  full  or  partial  decentralization  of 
applications-oriented  functions  to  user  departments.  If  not  planned,  such 
decentralization  could  have  negative  effects  on  both  organizational  and 
applications  effectiveness. 

•  Because  of  the  technical  difficulties  in  moving  into  a  true  micro-mainframe 
environment,  IS  should  enter  into  informal  (or,  if  warranted,  formal)  arrange- 
ments with  one  or  more  vendors  to  find  technical  solutions  to  micro-main- 
frame issues. 
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EXHIBIT  11-7 


RECOMMENDATIONS 

•  User-IS  Relationships 

-  IS:  Business  Orientation 

-  Users:  Knowledge  and 
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•  PC  Support  Unit 

•  IS  Initiatives:  Easy  Projects 

-  Experience 
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•  Consider  Decentralization 

•  Experiment  with  Vendors 
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END-USER  DIRECTIONS 


INTRODUCTION 

Much  attention  has  been  focused  on  downloading  data  to  spreadsheets  and 
other  micro  programs.  Several  dozen  such  products  have  been  released  and 
are  in  users'  hands,  and  at  least  as  many  more  have  been  announced  or  are  in 
beta  testing. 

Many  of  these  products  are  certainly  valuable  tools,  especially  since 
the  prior  alternative  was  to  manually  key  data  (often  from  reports 
produced  from  mainframe  systems).  Manual  rekeying  is  probably  still 
the  most  prevalent  form  of  micro-mainframe  (M-M)  interface. 

However,  it  became  clear  in  the  course  of  the  study  that  end  users 
already  have  their  sights  raised  considerably  higher  than  getting 
extracts  of  mainframe  data  to  use  in  calc  programs. 

Since  this  assertion  may  be  difficult  for  some  IS  managers  to  accept,  INPUT 
has  developed  case  studies  describing  how  six  companies  are  attempting  to 
push  the  edge  of  the  feasible,  from  an  M-M  standpoint. 

In  some  instances,  details  of  the  cases  have  been  altered  slightly  to 
preserve  anonymity.  Commercial  and  vendor  names  have  been  omitted 
unless  they  are  considered  generic  (e.g.,  the  PC/XT  or  UNIX). 
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At  the  end  of  each  study,  the  salient  findings  are  summarized. 

In  the  final  section  of  this  chapter,  commonalities  and  differences 
between  these  M-M  initiatives  are  described  and  analyzed,  and  overall 
conclusions  are  drawn. 

B.       A  BANK'S  MATRIXED  DATA  BASE 

•  A  major  bank's  loan  portfolio  is  kept  in  a  centralized  data  base.  The  data  in 
the  loan  portfolio  must  continually  be  consulted,  analyzed,  and  updated  by  two 
principal  types  of  users: 

Loan  teams— involved  in  procuring  broker  loans,  real  estate  loans, 
offshore  loans,  commercial  and  industrial  loans  (e.g.,  energy,  manufac- 
turing, transportation),  etc. 

Portfolio  management— cutting  across  loan  areas  to  perform  functions 
such  as: 

Reporting. 

Auditing. 

Collateral  evaluation. 

•  These  specialists  have  done  their  jobs  in  the  past  using  a  combination  of 
terminal  access  and  computer-generated  reports.  Over  a  year  ago  minicom- 
puters were  installed  to  download  the  broker  and  real  estate  portions  of  the 
data  base  so  that  these  portions  could  be  used  directly  by  loan  teams. 
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The  minicomputers  have  proved  to  be  quite  successful,  although  the 
bank  realizes  that  the  application  could  as  easily  have  been  accom- 
plished using  PCs.  The  bank  plans  to  "matrix"  the  central  data  base 
using  PCs,  as  shown  in  Exhibit  III- 1. 

in  many  respects  the  PC  alternative  is  seen  as  more  attractive  because 
of  lower  costs  and  because  of  the  wide  availability  of  packaged  soft- 
ware readily  usable  by  end  users. 

The  PC  would  be  used  to  originate  changes  to  the  central  loan  data 
base,  but  this  would  not  be  uploading  in  the  file  transfer  sense.  Rather, 
the  PC  would  originate  transactions  for  entry  through  the  conventional 
host  system. 

This  is  considered  necessary  for  control  and  security. 

Because  this  is  a  "matrixed"  file,  it  is  critical  that  the  central 
file  always  be  both  the  real  and  the  official  file.  Otherwise,  the 
portfolio  management  functions  would  be  ineffective. 

•  However,  the  approach  of  mimicking  traditional  file  transactions  is  felt  to  be 
too  simplistic  by  some  of  the  bank's  systems  planners.  Some  of  the  advanced 
proposals  include: 

Using  the  XT/370  as  the  user  PC  (which  shows  a  lack  of  understanding 
of  the  XT/370's  capabilities,  as  discussed  in  Chapter  V). 

Using  a  large  PC  or  a  small  mini  as  a  system  controller  between  the 
PCs  and  the  host  system. 

Writing  a  parameter-driven  package  for  reformatting  data  between  the 
mainframe  and  PC,  and  deciding  which  data  would  be  passed  to  the 
portfolio  management  subsystems. 
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EXHIBIT  lll-l 


CENTRAL  LOAN  DATA  BASE:    MATRIXED  WITH  PCs 
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This  package  would  be  designed  to  be  reusable  in  other  bank 
systems  with  similar  needs. 

.  However,  by  greatly  (ond  needlessly)  increasing  the  number  of 
interfaces,  the  complexity  of  resulting  systems  would  decrease 
security  and  probably  render  the  software  design  unfeasible. 

•  Conclusions:  The  system  as  planned  will  undoubtedly  be  a  success,  because  it 
is  an  evolutionary  increment  over  prior  systems. 

Users  and  IS  have  learned  to  work  well  together. 

While  the  IS  technical  staff  would  like  to  try  out  more  "interesting" 
solutions,  these  are  not  used  until  proven. 

C.       THE  MICRO  AS  CHANGE  AGENT  IN  A  RETAIL  ORGANIZATION 

•  A  large  retail  store  has  recently  been  upgrading  its  centralized  hardware  and 
software.  Consequently,  IS  management  has  not  paid  much  attention  to  the 
Merchandising  Department's  parallel  acquisition  of  an  IBM  PC/XT. 

IS  believes  that  the  XT  will  be  used  by  Merchandising  only  for  pro- 
ducing better  ordering  estimates  to  be  used  by  the  host-based  pur- 
chasing/inventory management  system,  as  shown  in  Exhibit  1 1! -2. 

However,  the  merchandising  unit  believes  the  XT  will  finally  give  them 
a  chance  to  really  know  the  status  of  orders. 

•  From  the  users'  standpoint  the  problem  with  the  host-based  system  is  that  it 
does  not  (and  perhaps  cannot)  present  an  accurate  view  of  the  order  situation 
during  peak  periods. 
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EXHIBIT  III-2 
SHIFTING  OF  CONTROL  FROM  MAINFRAME  TO  MICRO 
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Although  data  is  collected  via  terminals,  the  core  system  is  really  a 
batch  system.  The  purchase  authorization/order  cycle  can  easily  take 
a  week  before  Merchandising  knows  that  an  order  was  received  by  a 
vendor.  Transaction  failures,  corrections,  and  errors  in  any  number  of 
places  make  the  system  virtually  unusable  as  an  operational  or 
management  tool. 

The  buyers  within  the  Merchandising  Department,  in  consequence,  have 
always  maintained  their  own  paper  files  to  tell  them  what  is  really 
happening. 

•  The  XT  has  become  the  system  that  is  used  for  both  analysis  and  operation  by 
the  Merchandising  Department.  There  is  even  a  good  chance  that  the  buyers 
will  merge  some  or  all  of  their  paper  files  with  the  XT  files  as  buyers  become 
comfortable  with  the  XT.  This  evolving  situation  leaves  IS  in  a  difficult 
position. 

The  host  system  will  not  be  completely  replaced.  Its  central  ac- 
counting and  payables  functions  will  remain.  However,  its  perceived 
added  value  will  be  relatively  low. 

The  Merchandising  Department  will  tend  to  neglect  host  transactions  in 
favor  of  XT  transactions  wherever  there  is  a  time  or  resource  con- 
flict. This  will  create  increasing  numbers  of  impurities  in  the  central 
data  base.  This  will  be  accentuated  by  the  decreasing  use  of  centrally 
prepared  data  by  informed  users  so  that  data  or  processing  anomalies 
will  not  be  identified  quickly  (or  at  all).  The  corporate  data  base  will  - 
be  devalued  valueless. 

Since  the  Merchandising  Department  is  highly  motivated,  the  XT 
approach  stands  a  good  chance  of  success.  To  the  extent  that 
Merchandising  is  successful,  the  3081  will  become  a  sort  of  backend  to 
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the  XT.  IS  may  find  it  embarrassing  to  justify  the  significant  increase 
in  the  expense  of  central  data  processing,  as  a  result  of  the  new 
systems  just  added. 


•  Both  IS  and  general  management  are  virtually  oblivious  to  these  problems. 

Both  are  supportive  of  Merchandising's  efforts  to  be  "modern." 

IS  management  is  essentially  technically  oriented.  IS  does  not  under- 
stand how  retail  buyers  must  function. 

•  Conclusions:  This  project  could  become  a  success  in  spite  of  the  technical 
pitfalls  lying  ahead. 

The  end  users  want  it  to  work  and  have  clearly  defined  their  own  needs. 

It  is  more  likely,  however,  that  Merchandising  in  meeting  its  own  needs 
will  needlessly  damage  the  integrity  of  corporate  data. 

D.       ORDER  ENTRY  IN  CHEMICAL  AND  PETROLEUM  COMPANIES 

•  Order  entry  is  the  critical  operational  underpinning  to  a  company's  marketing 
and  financial  success.  However,  people  sometimes  underestimate  (or  are 
unaware  of)  the  complexity  of  many  of  the  large  computerized  order  entry 
systems  that  have  been  implemented  in  recent  years. 

This  ignorance  of  the  complexity  of  underlying  system  and  user  needs 
among  otherwise  informed  users,  coupled  with  a  sometimes  naive  belief 
in  the  powers  of  the  PC,  will  cause  increasing  problems  for  some 
companies. 
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This  is  the  case  for  two  large  firms  (a  specialty  chemical  manufacturer 
and  a  petroleum  product  producer)  INPUT  interviewed.  In  both  cases  a 
sophisticated  centralized  order  entry  system  has  been  developed  over 
the  last  decade. 

•  Exhibit  1 11-3  shows  the  main  components  of  these  order  entry  systems.  These 
systems  and  their  resulting  problems  are  quite  similar  in  their  general  design 
and  operation,  and  will  be  discussed  jointly  below. 

Note  that  "order  processing"  is  only  one  of  the  system's  functions  and, 
arguably,  not  the  most  important  one. 

The  order  entry  system  is  closely  tied  to  several  financial 
systems. 

The  order  entry  process  is  increasingly  seen  as  a  logical  exten- 
sion of  the  production  process—both  the  frontend  (production 
planning)  and  the  backend  (shipping  and  inventory). 

A  very  sophisticated  set  of  data  bases  has  been  developed  to  support 
the  order  entry  process: 

Complex  product  and  customer  directories  (coded  information 
on  subsidiaries,  plant  locations,  even  building  and  loading  dock 
locations)  have  been  developed. 

Because  of  increasing  price  competition,  the  sales  and  mar- 
keting departments  have  developed  an  increasingly  complicated, 
not  to  say  confusing,  set  of  discount  arrangements.  IS  has 
successfully  been  able  to  capture  this  in  computer  logic  (which 
is  often  changed),  as  shown  in  Exhibits  II 1-4  and  1 11-5. 
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EXHIBIT  III-3 


ORDER  ENTRY  APPLICATION  COMPONENTS  (LOGICAL  VIEW) 
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EXHIBIT  m-4 


CURRENT  DISCOUNT  STRUCTURE  (Logical  View): 
PRINCIPAL  DISCOUNT  FACTORS 


Specific 
Products 
and  Product 
Combinations 
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Effects 
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EXHIBIT  III-5 


CURRENT  DISCOUNT  STRUCTURE  (Logical  Vi 
OTHER  DISCOUNT  FACTORS 
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Because  these  systems  are  complex  and  cross  many  departmental  boundaries, 
the  order  entry  system  does  not  have  a  departmental  owner  or  champion.  In 
fact,  the  only  people  who  may  fully  understand  the  interrelationships  of  the 
various  components  are  a  few  people  on  the  IS  staff  (not  including  senior  IS 
management).  This  has  already  had  the  following  unfortunate  consequences? 

The  complexity  of  the  system  causes  it  to  sometimes  produce  unex- 
pected results  that,  while  not  true  errors,  are  still  wrong  in  the  eyes  of 
users. 

Even  when  the  system  is  functioning  perfectly  well,  users  must  be 
educated  on  how  apparently  unexpected  results  are  perfectly  valid 
(e.g.,  the  workings  of  the  discount  schedule). 

Because  of  these  problems  in  user  understanding,  the  IS  staff  is  very 
cautious  in  accepting  and  implementing  changes  to  the  order  entry 
system.  This  has  produced  enormous  backlogs  that  have  given  both  the 
order  entry  system  and  IS  a  very  bad  name  among  users. 

IS  is  the  good-faith  defender  of  an  adequately  functioning  system  that 
produces  significant  corporate  benefits.  However,  it  receives  no  credit 
for  this.  Instead,  IS  is  widely  believed  to  be  holding  onto  power  by 
controlling  this  system. 

Thus  it  should  not  be  surprising  that  when  the  first  micros  came  on  the  scene 
in  the  early  1980s,  many  of  the  dispersed  branch  office  users  (supply  points, 
sales  offices,  warehouses,  etc.)  saw  the  acquisition  of  an  "order  entry"  PC  as 
the  solution  to  their  problems  in  dealing  with  a  quirky,  difficult-to-use  host 
system. 

These  usually  fuzzy  and  technically  deficient  requests  were  rejected 
individually  by  IS.  Unfortunately,  IS  did  not  use  this  as  an  opportunity 
to  educate  all  users  on  how  (and  why)  their  system  operated.  Instead, 
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IS  merely  said  that  standalone  PCs  could  not  be  fitted  into  an  inter- 
active environnnent. 

As  different  end  users  saw  how  they  had  been  "defeated"  on  this  issue, 
increased  resentment  toward  the  perceived  IS  technocrats  built  up. 

•  The  end  users  have  since  become  generally  aware  of  the  potential  for  M-M 
connections  and  have  seen  the  potential  for  applying  this  to  the  order  entry 
problem.  The  IBM  3270  PC  has  been  an  especially  potent  symbol  for  them 
(although  the  3270  PC  may  not  in  fact  be  best  suited  to  their  needs).  The 
dispersed  end  users  have  learned  from  their  past  mistakes: 

They  are  approaching  IS  as  a  group  so  they  cannot  be  "defeated" 
piecemeal. 

They  are  adopting  what  is  to  them  a  very  plausible  rationale: 

.  The  3270  PCs  are  not  meant  to  replace  the  main  system  but  to 
supplement  it,  especially  during  peak  periods. 

.  The  local  systems  can  deal  more  responsively  with  local  cus- 
tomers and  will,  in  fact,  often  have  a  better  knowledge  of  local 
supply  and  inventory  conditions  than  the  centralized  system  will 
show. 

The  local  systems  will  faithfully  produce  transactions  to  feed 
the  central  systems  so  that  no  corporate  information  is  lost. 

Because  of  bad  feelings  that  have  long  existed  and  are  increasing,  this 
issue  has  become  for  the  users  as  much  an  emotional  and  political  issue 
as  a  business  and  systems  problem. 
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IS  still  does  not  see  the  order  entry  system  as  a  central  system  extending  its 
nerve  endings  throughout  the  corporation.  IS  management  takes  "order  entry" 
at  its  face  value  and  sees  it  more  or  less  as  the  property  of  the  branch  loca- 
tions that  are  agitating  for  change. 

The  best  response  would  be  to  fight  fire  with  fire  and  mobilize  the 
other  heavy-hitter  groups  (e.g.,  marketing,  manufacturing,  finance) 
that  interface  with  the  system  to  protect  their  interests. 

Being  politically  naive  and  technically  oriented,  IS  instead  has  sug- 
gested a  systems  study  to  see  how  an  M-M  link  could  be  accommo- 
dated. 

This  has  only  further  infuriated  the  branch  users,  especially  since  they 
now  believe  that  IS's  anti-standalone-PC  arguments  were  not  made  in 
good  faith  but  were  just  excuses  to  save  the  "IS  empire." 

The  branch  users  have  formulated  difficult-to-deny  requests  for  local 
customer  lists  and  records,  product  volume  and  mix  discounts,  and  transaction 
formats. 

They  have  a  very  simplified  view  of  how  the  order  entry  system  works 
from  their  standpoint,  as  shown  in  Exhibit  1 11-6. 

Either  they  are  oblivious  to  the  interplay  between  order  entry  and 
financial  and  manufacturing  systems  or  they  argue  that  their  local 
information  is  better  anyway. 

Because  the  centralized  discount  calculation  has  in  fact  worked  well, 
they  are  often  not  aware  of  the  complex  and  subtle  factors  that  can 
routinely  influence  discounts.  (Or  when  they  are  aware,  they  often 
would  not  wish  to  be  constrained  by  central  discount  rules  anyway.) 
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lEXHIBIT  III-6 


DISTRIBUTED  USER  VIEW  OF  ORDER  ENTRY  APPLICATION 


Discount  Structure  View: 


 ► 

Order  Size 
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In  these  two  companies  it  is  ainnost  certain  that  multiple  deviant  local 
systems  will  be  developed  with  little  or  no  IS  control  or  coordination. 

These  deviant  local  systems  are  bound  to  corrupt  the  data  that  is  going 
into  the  central  system,  which  will  increasingly  be  treated  as  a  pro 
forma  afterthought  by  the  branch  users. 

This,  in  turn,  will  shake  the  confidence  of  the  headquarters  users 
(finance,  manufacturing,  etc.),  and  they  too  may  turn  on  IS  and  the 
central  system  with  incalculable  consequences. 

Conclusions;  Win-win  situations  should  always  be  a  systems  goal.  Unfor- 
tunately, this  has  turned  into  a  lose-lose  situation. 

There  is  a  gulf  of  ignorance  between  the  end  users  and  IS  management. 

The  end  users  do  not  appreciate  technical  issues  and  problems. 

Top  IS  managers  have  raised  the  drawbridge  around  their  tech- 
nical world. 

While  IS  is  probably  correct  to  say  that  a  difficult  technical  problem 
needs  more  study,  this  is  an  answer  that  end  users  have  heard  too 
often. 

An  organizational  change  is  probably  the  only  solution  to  this 
problem.  That  is,  IS  top  management  (at  a  minimum)  would  change, 
and  data  processing  functional  responsibilities  would  possibly  be  re- 
structured. 
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E.       THE  UNIX  TIME  BOMB 

•  A  major  energy  firm  has  upgraded  its  information  center  services  to  provide 
downloaded  data  for  use  on  IBM  PCs,  as  shown  in  Exhibit  1 11-7. 

In-house  modification  to  an  ASCII  communications  package  enables 
host  summary  file  data  to  be  transmitted  to  PCs  in  VisiCalc-com- 
patible  form,  as  shown  on  line  (a)  of  the  exhibit. 

The  service  has  worked  well,  even  though  downloading  is  handicapped 
by  the  low  speed  and  unreliability  inherent  in  asynchronous  communica- 
tions. 

The  success  of  using  PCs  has  whetted  user  appetites  for  more.  How- 
ever, users  have  had  differing  ideas  on  what  "more"  consists  of. 

Some  want  much  more  data  than  current  methods  allow;  they 
also  want  to  be  able  to  perform  much  more  complex  analyses. 

Others  want  to  share  data  between  users,  either  on  the  same 
machine  or  on  different  machines. 

Still  others  want  to  take  over  analytic  and,  perhaps,  operational 
tasks  now  performed  on  the  host  system. 

•  Although  they  are  knowledgeable  about  their  own  functions,  the 
users  are  not  very  informed  on  data  processing  issues.  They 
believe,  however,  that  the  capabilities  represented  by  the 
PC/XT  or  similar  machine  will  give  them  the  upgrade  needed. 

•  Some  IS  staff  members  (with  no  discouragement  from  IS  management)  have 
led  users  to  believe  that  UNIX  is  the  answer.  UNIX  is: 
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EXHIBIT  III-7 


AN  UNPLANNED  EVOLUTION  INTO  A  UNIX  ENVIRONMENT 
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Very  powerful  and  flexible. 

Able  to  provide  function-specific  "shells"  to  users. 
Multiuser  and  multitasking. 

Most  suited  for  the  more  powerful  micros,  both  current  models  and 
those  on  the  horizon. 

•  This  message  has  met  a  receptive  audience.    Many  of  the  users  have  heard 
enough  about  UNIX  to  be  predisposed  in  its  favor.  They  are  now  pushing  IS  to: 

Install  UNIX  software. 

Implement  UNIX-based  micro  systems. 

Modify  host  systems  to  take  account  of  these  new  locally  based  capa- 
bilities. 

•  IS  management  is  willing  to  provide  several  UNIX  experts  (on  a  relatively 
junior  staff  level)  to  help  users  make  changes  on  a  local  basis.  But  IS 
management  is  totally  unwilling  to  make  a  central  IS  commitment  to  a  UNIX- 
type  solution.  The  IS  interest  in  UNIX  is  only  one  of  a  number  of  esoteric  or 
experimental  approaches  that  have  gained  moderate  amounts  of  resources  and 
backing  within  IS. 

Although  IS  has  spoken  of  decentralization  and  user-oriented  develop- 
ment, what  IS  management  means  by  this  is: 

.         User   department   funding  of  development  and  maintenance 
activities  that  are  still  centrally  managed. 
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User  involvement  in  specific  applications,  including  user  direc- 
tion of  system  development  projects. 

.         An  IS  organization  that  is  applications  system  oriented. 

IS  itself  is  still  centrally  controlled  and,  equally  important,  still  be- 
lieves in  massive  host-based  systems.  IS's  major  financial  commitment 
is  still  to  traditional  IMS-based  systems.  Its  design  philosophy  still 
revolves  around  the  traditional  IMS-based  systems  as  well. 

More  tellingly,  IS's  senior  technical  staff  identifies  very  closely  with 
large-scale  IBM  operating  systems,  DBMSs,  and  communications 
systems.  These  people  are  highly  skilled  (and  highly  paid),  and  some 
are  worried  that  their  marketplace  worth  may  decrease  if  UNIX  (or 
other  M-M  approaches)  begins  to  change  the  rules  and  practice  of 
system  building. 

•  Senior  IS  management  is  less  emotionally  committed  to  centralized  solutions 
than  is  the  senior  technical  staff.  However,  senior  management  is  technically 
obsolescent,  and  managers  are  not  willing  to  make  decisions  that  go  against 
their  senior  technical  staff  in  areas  perceived  to  be  largely  technical. 

Consequently,  IS  management  has  temporized  on  the  UNIX  issue.  They 
did  not  discourage  the  UNIX  missionaries,  because: 

The  IS  department  has  had  a  long  tradition  of  being  technically 
innovative. 

"UNIX"  is  a  powerful  if  not  a  very  well  understood  word. 

This  corporation's  users,  like  those  of  most  user  departments, 
have  become  restive  as  a  result  of  backlogs,  inflexible  systems, 
etc. 
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IS  management  sincerely  wants  to  put  more  capabilities  into  the 
hands  of  users. 

IS  management  does  not  fully  understand  the  self-interest  that  is 
largely  motivating  its  senior  technical  staff's  opposition  to  UNIX. 
Consequently,  IS  management  has  fallen  into  the  position  of  agreeing 
to  UNIX  use  on  a  very  limited  basis;  i.e.,  there  will  be:  , 

No  central  IS-provided  training  or  support. 

No  senior  staff  involvement. 

No  dislodgement  or  modification  to  current  or  planned  host- 
based  systems. 

Neither  IS  management  nor  the  user  departments  are  yet  conscious  of  the 
magnitude  of  their  problem;  they  are  on  a  collision  course. 

IS  believes  that  UNIX  is  only  an  upgrade  to  VisiCalc,  as  shown  on  line 
(a)  of  Exhibit  III-7.  In  IS's  view,  nothing  essential  should  or  can  change 
in  the  technical  or  power  relationships. 

Key  users,  on  the  other  hand,  see  UNIX-based  systems  as  the  beginning 
of  independence  from  what  are  (in  their  view)  torpid.  Ineffectual 
centralized  systems,  as  shown  on  line  (b)  of  the  exhibit. 

Users  do  not  understand  the  reasons  for  IS  management's  and  its  senior  tech- 
nical staff's  almost  casual  involvement  in  these  technical  issues. 

Users  have  also  tacitly  assumed,  but  in  a  totally  different  way,  that 
UNIX  is  only  an  upgrade  to  VisiCalc. 
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They  believe  that  off-loaded  host  functions  can  be  taken  over  as  easily 
by  using  UNIX  as  downloaded  data  could  be  handled  using  VisiCalc. 
This  is,  of  course,  totally  untrue  but  will  become  apparent  to  users  only 
after  a  considerable  expenditure  of  money  and  time. 

•  Note:  For  additional  analysis  of  the  UNIX  issue,  see  Section  A  of  Chapter  V. 

•  Conclusions;  Technical  enthusiasts  can  often  lead  the  uninitiated  astray. 

More  tellingly,  IS  management  has  not  adopted  a  well-thought-out 
position  on  what  is  a  difficult  and  potentially  disruptive  issue. 

Although  no  disaster  will  occur,  there  will  be  much  wasted  time  and 
effort.  IS  will  lose  face  in  the  estimation  of  its  users. 

F.       AN  INSURER'S  MICRO-MAINFRAME  NONCONNECTION 

•  A  leading  property/casualty  insurance  company  decided  several  years  ago  to 
convert  from  a  relatively  primitive  in-house  system  to  a  leading  vendor's 
package.  The  IS  department  was  the  major  proponent  of  the  vendor  selected. 

Unfortunately,  the  initial  stages  of  installation  were  not  smooth,  and 
key  users  became  quite  concerned  about: 

The  length  of  time  full  installation  would  take  (several  years). 

The  expense. 

The  changes  users  would  have  to  make  to  conform  to  the 
package  (rather  than  vice  versa). 

The  apparent  inflexibility  of  the  system,  once  installed. 
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In  the  meantime,  the  users  had  learned  of  a  new  vendor's  micro-based 
software  that  appeared  to  them  to  have  significant  advantages, 
including: 

.         Installation  by  independent  I ine-of -business  module  (e.g.,  auto- 
mobile, business  owners,  etc.). 

High  tailorability. 

Quick  installation. 

Lower  cost. 

•  The  IS  department  was  unwilling  to  examine  this  new  alternative  in  view  of 
the  fact  that  much  company  time  and  money  had  been  spent  in  reaching  what, 
after  all,  was  a  contractual  commitment  with  the  first  vendor. 

However,  the  users  became  increasingly  convinced  of  the  correctness 
of  their  position  and  elevated  the  question  to  CEO  level. 

The  IS  vice  president  refused  to  have  anything  to  do  with  such  a  "wild" 
scheme,  and  when  the  dust  had  settled,  one  of  the  operational  vice 
presidents  had  assumed  authority  for  implementing  the  micro-based 
system  in  a  number  of  business  areas. 

The  mainframe-based  package  was  cancelled  for  the  commercial 
insurance  part  of  the  business. 

IS  was  to  play  little  role  in  the  implementation. 

•  The  stage  was  set  for  disaster. 

However,  the  disaster  did  not  occur. 
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The  installation  of  the  micro  system  has  been  a  success,  meeting 
almost  all  user  expectations  (many  more  expectations  than  most 
similar  mainframe  implementations  meet). 

The  success  was  due  to  a  combination  of  the  vendor's  product  and, 
especially,  user  commitment  and  involvement. 

One  of  the  features  that  the  users  found  especially  attractive 
about  this  product  was  that  knowledgeable  user  personnel  could 
interact  directly  with  the  software  during  system  construction. 

.    '     This  interaction  had  a  significant  impact  on  speed,  accuracy, 
and  acceptance. 

In  a  way,  the  project  has  been  too  successful.  The  I ine-of -business  managers 
are  running  what  are,  in  essence,  miniature  data  processing  departments. 

Data  to  support  the  traditional  host-based  accounting  and  statistical 
systems  is  rekeyed  from  micro  output  into  the  host  system,  as  shown  in 
Exhibit  111-8. 

This  is  an  ironic  mirror  image  of  many  current  micro  downloading 
practices. 

What  is  finally  beginning  to  be  discussed  within  the  company  is  a  means  by 
which  a  new  host  data  base  could  be  constructed  to  collect  data  of  corporate 
interest  now  being  generated  by  the  micros. 

Conclusions:  The  somewhat  surprising  success  of  this  end-user  initiative  was 
due  to  deep  commitment,  good  project  leadership,  and  a  good  product  founda- 
tion. 


-53  - 

©  1984  by  INPUT.  Reproduction  Prohibited. 


INPUT 


EXHIBIT  III-8 


AN  INSURANCE  COMPANY'S  MICRO-MAINFRAME  NONCONNECTION 
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Unless  the  micro  IS  kingdoms  are  reintegrated,  the  inevitable  problems 
of  inconsistency  and  incompatibility  will  arise.  This  is  doubly  true 
since  success  was  due  partly  to  a  fortunate  combination  of  personali- 
ties. 

There  will  be  problems,  in  the  after-the-fact  integration  of  subsets  of 
locally  generated  data  into  a  corporate  data  base. 

SUMMARY 

These  six  companies  show  a  great  diversity  in  their  M-M  initiatives  and  the 
manner  in  which  the  initiatives  arose,  as  shown  in  Exhibit  1 1 1-9. 

One  common  thread  is  that  success  is  highly  dependent  on  the  technical 
adequacy  of  the  plan. 

The  two  organizations  with  high  success  probabilities  are  both  using 
proven  technology.  (The  bank  is  using  an  evolutionary  version  of  an 
earlier  system;  the  insurance  company  is  using  a  vendor's  package.) 

However,  user  understanding  and  commitment  is  necessary,  too,  for  the 

"micro"  part  of  micro-mainframe  to  work  well. 

It  is  also  noteworthy  that  in  four  of  the  six  companies  the  initiative  came 
from  users. 

This  was  not  surprising  in  view  of  the  relatively  low  quality  of  relation- 
ships between  IS  and  these  users. 

Users  are  taking  these  kinds  of  initiatives  now  in  part  because  they  are 
making  an  imperfect  analogy: 
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Micros  have  proven  easy,  effective,  and  inexpensive  to  perform 
analytical  work  (indeed,  better  in  these  respects  than  host 
systems,  in  the  eyes  of  many  users). 

Therefore,  the  same  kind  of  benefits  accrue  when  switching 
from  analytical  to  operational  uses.  However,  these  uses  are 
quite  different,  as  shown  in  Exhibit  111-10. 

It  should  be  emphasized  that  these  users  were  not  concerning  themselves  with 
trivial  issues;  the  micro-based  systems  they  want  are  central  to  their  opera- 
tions. 

In  a  way,  these  ambitious  goals  are  a  compliment  to  data  processing 
and,  perhaps  even  more  so,  to  the  mystique  of  the  micro. 

It  also  symbolizes  user  frustration  with  conventional  data  processing, 
as  the  users  see  it.  There  is,  unfortunately,  little  that  IS  can  do  to 
relieve  these  frustrations,  at  least  in  the  short  run. 

In  organizations  where  IS-user  relationships  are  not  good,  these  user  initia- 
tives will  grow  more  common,  at  least  for  a  few  years,  until  the  news  of  the 
high  casualty  rates  filters  back  from  the  front  lines  of  M-M  implementations. 
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EXHIBIT  111-10 

DIFFERENCES  BETWEEN  ANALYTIC  AND  PRODUCTION  SYSTEMS 
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MICRO-MAINFRAME  FUTURE  DIRECTIONS 


IV 


MICRO-MAINFRAME  FUTURE  DIRECTIONS 


A.       SHARED  FUNCTIONALITY 

•  INPUT  has  coined  the  term  "shared  functionality"  to  describe  one  of  the  key 
characteristics  of  future  M-M  applications. 

•  The  concept  of  shared  functionality  is  straightforward;  it  is  the  sharing  of 
processing  and  data  between  mainframe  and  micro,  as  shown  in  Exhibit  IV- 1. 
It  is  allied  but  distinct  from  older  views  of  distributed  data  processing 
(DDP).  DDR  is  different  in  that: 

It  was  usually  seen  as  being  controlled  from  a  central  point,  while 
shared  functionality  is  based  more  on  equality. 

A  major  motivating  force  was  IS  efficiency,  rather  than  meeting  end- 
user  needs. 

Perhaps  more  importantly,  DDP  has  always  been  more  of  a  theoretical 
than  an  implementable  approach. 


•  What  is  somewhat  surprising  is  that  fully  85%  of  the  corporate  respondents  to 
the  INPUT  survey  subscribe  to  this  M-M  view.  (This  percentage  would  be  far 
more  surprising  if  not  for  the  circumstances  described  in  Section  B  of  Chapter 
I.) 
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EXHIBIT  IV-1 


RESPONDENTS'  VIEW  OF  SHARED  FUNCTIONALITY 
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The  case  studies  in  Chapter  III  bear  out  this  attitude  on  the  part  of 
users. 

Needless  to  say,  this  kind  of  M-M  systenn  does  not  exist  in  most 
companies  today.  In  addition,  based  on  INPUT'S  experience,  many  key 
people  in  IS  organizations  have  not  yet  accepted  this  view.  Rather, 
their  view  would  be  more  like  that  in  Exhibit  IV-2,  where  suitably 
protected  data  flows  from  mainframes  to  micros.  Meaningful  (i.e., 
nonanalytic)  production  processing  is  confined  to  mainframe  systems. 

Of  course,  this  high  level  of  agreement  (agreement  that  shared  functionality 
is  the  chief  characteristic  of  M-M  applications)  could  only  have  indicated 
agreement  with  broad  principles.  Consequently,  respondents  were  asked  if 
they  felt  "most  applications  that  are  now  host-based  will  (in  three  to  five 
years)  have  a  considerable  amount  of  functionality  taken  over  by  personal 
computers  linked  to  the  host." 

Naturally,  there  was  far  more  diversity  here.  However,  three-quarters 
of  respondents  see  host  applications  having  these  shared  functionality 
characteristics  within  five  years,  as  shown  in  Exhibit  IV-3.  About  a 
quarter  of  all  respondents  were  very  positive  in  their  support  of  this 
position;  many  were  already,  in  fact,  implementing  M-M  applications. 

This  is  consistent  with  the  fact  that  virtually  all  respondents  were  able 
to  give  several  examples  of  M-M  applications  implemented  or  in  the 
process  of  being  implemented.  Although  most  of  these  applications 
were  rather  primitive,  they  were  nontrivial. 

The  average  score  supporting  shared  functionality  (on  a  scale  of  +5  to  -5)  was 
+  1.7.  The  most  favoroble  group  had  a  score  of  +4.5,  and  the  negative/neutral 
group  scored  only  -2.2. 
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EXHIBIT  IV-2 


KEY  I.S.  MANAGERS'  VIEW  OF  SHARED  FUNCTIONALITY 
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EXHIBIT  !V-3 


EXPECTATION  OF  EXTENSIVE 
HOST-MICRO  SHARED  FUNCTIONALITY  APPLICATION 
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•  Generally  speaking,  the  more  positive  attitudes  toward  shared  functionality, 
as  shown  by  Exhibit  IV-4,  were  held  by  activist-type  organizations.  These 
organizations: 

Planned  to  use  outside  sources  of  assistance. 

Were  more  aware  of  potential  problems. 

Saw  more  complex  uses  of  M-M  links. 

•  Those  organizations  less  positive  toward  shared  functionality  tend  to  be  more 
passive  in  their  plans  for  M-M  connectivity,  as  shown  in  Exhibit  IV-5. 

B.       TYPES  OF  MICRO-MAINFRAME  LINKAGES 

•  Conceptually,  M-M  connectivity  ranges  from  the  manual  entry  of  previously 
unautomated  data  to  interactive,  segmented  programs. 

Most  current  linkages  are  products  relatively  low  in  the  connectivity 
"hierarchy,"  as  shown  in  Exhibit  IV-6. 

However,  the  goal  of  shared  functionality  implies  reaching  the  "4"  or 
"5"  level  shown  on  the  exhibit. 

•  This  was  confirmed  by  asking  corporate  IS  respondents  whether  they  saw  M-M 
links  as  being: 

Predominantly  interactive. 

Predominantly  on-line  batch  (i.e.,  where  the  micro  performs  processing 
on  a  standalone  basis  and  the  micro  and  host  periodically  exchange 
data). 

Equally  interactive  and  on-line  batch. 
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EXHIBIT  IV-4 


ATTITUDES  TOWARD  SHARED  FUNCTIONALITY  APPLICATIONS: 
SELECTED  GROUPS  WITH  HIGHER  THAN  AVERAGE  ATTITUDES 
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EXHIBIT  IV-5 

ATTITUDES  TOWARD  SHARED  FUNCTIONALITY  APPLICATIONS: 
SELECTED  GROUPS  WITH  LOWER  THAN  AVERAGE  ATTITUDES 
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EXHIBIT  IV-6 


HIERARCHY  OF  MICRO-MAINFRAME  CONNECTIVITY 
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Somewhat  surprisingly,  three-quarters  of  the  corporate  IS  respondents  see  half 
or  more  of  their  future  linkages  as  being  at  least  partially  interactive,  as 
shown  in  Exhibit  IV-7. 

This  places  the  corporate  respondents  on  the  most  demanding,  leading  edge  of 
connectivity;  that  is,  as  shown  in  Exhibit  IV-8,  they  require: 

Interactive  accessi 

On-demand  file  elements. 

Generalized  (as  opposed  to  vendor  proprietary)  files. 

In  contrast,  vendor  M-M  links  of  a  representative  selection  of  leading  vendors 
fall  short  in  one  or  more  areas,  as  shown  in  Exhibits  IV-9  through  IV- 1 2. 

These  vendor  links  are  certainly  only  the  first  generation  of  such  products. 
Candid  vendors  will  admit  that  many  (if  not  all)  vendor  links  were  rapidly  put 
together  to  get  products  into  the  marketplace. 

Because  of  their  origins,  the  vendor  products  have  little  in  common, 
from  the  standpoint  of  concept,  design,  or  operation.  These  products 
are  generally  very  proprietary  in  nature  (i.e.,  they  link  to  a  specific 
vendor's  product  at  one  or  both  ends  of  the  link). 

As  a  class,  these  products  should  be  viewed  as  stopgaps  for  vendors,  IS 
departments,  and  users.  They  are  certainly  better  than  rekeying  into 
spreadsheets  but  are  in  most  cases  probably  not  the  foundation  for 
long-term,  key  M-M  systems. 

With  this  background,  it  is  understandable  that  vendors  were  much  more 
cautious  than  IS  respondents  were  in  judging  the  type  of  future  M-M  connec- 
tivity. 
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EXHIBIT  IV-7 


TYPES  OF  MICRO-MAINFRAME  LINKAGES  FORESEEN 
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EXHIBIT  IV-8 


MICRO-MAINFRAME  LINKAGE  ALTERNATIVES 
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EXHIBIT  IV-9 


CULLINET  MICRO-MAINFRAME  OFFERINGS 
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EXHIBIT  IV-10 


McCORMACK  &  DODGE  MICRO-MAINFRAME  OFFERING 
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INFORMATICS  MICRO-MAINFRAME  OFFERING  (VISIANSWER) 
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Only  half  as  many  vendors  as  IS  respondents  saw  Interactive  M-M 
applications  predominating,  as  shown  in  Exhibit  IV- 1 3. 

Three-quarters  of  vendors  see  on-line  batch  applications  playing  a  key 
role;  this  is  a  mirror  image  of  what  IS  respondents  see. 

For  reasons  that  will  be  explored  more  thoroughly  in  the  next  chapter, 
INPUT  believes  that  the  vendor  assessment  is  more  realistic:  the 
technology  is  largely  here  now  for  on-line  batch  applications,  and  this 
approach  will  always  be  easier  to  implement,  with  less  risk. 

C.       DEVELOPMENT  APPROACHES  TO  MICRO-MAINFRAME  APPLICATIONS 


•  These  are  three  basic  strategies  for  developing  M-M  applications: 

Modifying  existing  software. 

Adding  new  application  codes  to  an  existing  data  base. 
Writing  entirely  new  applications. 

•  IS  respondents  were  somewhat  more  in  favor  of  the  modification  strategy  than 
vendors  were,  as  shown  in  Exhibit  IV- 1 4. 

Interestingly,  vendors  were  somewhat  more  balanced  in  their  appraisals 
and  tended— more  than  IS  staff  did— to  see  new  applications  as 
necessary. 

The  vendors  were  undoubtedly  affected  by  hopes  that  existing 
software  or  DBMS  could  be  used  (when  the  vendor  respondents 
offered  one). 
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EXHIBIT  lV-13 


INTERACTIVE  VERSUS  ON-LINE  BATCH  MICRO-MAINFRAME  APPLICATIONS 
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EXHIBIT  IV-14 
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INPUT  believes  that  new  applications  will  be  needed  for  most 
non-trivial  M-M  applications  because  of  the  difficulty  in  retro- 
fitting M-M  applications  to  existing  systenns. 

.         Consequently,  even  the  vendor  assessment  of  the  need  for  new 
applications  is  almost  certainly  an  understatement. 

Being  committed  to  one  particular  strategy  does  not  exclude  support  for  other 
strategies.  In  fact,  the  corporations  most  in  favor  of  a  particular  strategy 
supported  other  strategies  as  well,  as  shown  in  Exhibit  IV- 1 5. 

IS  departments  are  not  planning  to  go  it  alone.  As  reported  earlier,  most 
corporations  have  several  M-M  applications  in  place  or  in  development. 

Over  half  of  these  have  relied  on  vendor  assistance  for  at  least  part  of 
the  work,  as  shown  in  Exhibit  IV- 1 6. 

However,  for  M-M  projects  in  the  planning  or  concept  stage,  fully  85% 
plan  vendor  involvement.  This  increase,  in  what  was  already  a  rela- 
tively large  number,  reflects: 

More  difficult  M-M  projects. 

Increased  vendor  capabilities. 
.         An  increased  awareness  of  vendor  capabilities. 
The  assistance  received  runs  the  gamut  from: 
Packages  used  without  modification. 
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EXHIBIT  IV-15 


EXTENT  TO  WHICH  A  PARTICULAR 
DEVELOPMENT  STRATEGY  SUPPORTS  OTHER  STRATEGIES 
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N7A  =  Not  Applicable 
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EXHIBIT  IV-16 

VENDOR  INVOLVEMENT  IN  MICRO-MAINFRAME  APPLICATIONS 


Currently  Implemented  or  in  Development 


In  Planning  or  Concept  Stage 


I    I  Vendor  Involvement         ^    In-House  Implementation 
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Packages  used  with  extensive  modification  (quite  common  at  this 
stage),  with  modification  supplied  by: 

In-house  staff. 

Professional  service  firms. 

Custom  programming  from  outside  vendors. 
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V   MICRO-MAINFRAME  ISSUES 


MICRO-MAINFRAME  ISSUES 


A.       TECHNOLOGY  ISSUES 

•  There  are  three  main  technical  issues  affecting  end-user  M-M  applications: 

The  XT/370. 
UNIX. 

Data  synchronization. 
I.       THE  XT/370 

•  In  concept,  the  XT/370  allows  users  to  "have  their  cake  and  eat  it  too." 

The  "mainframe"  is  brought  to  the  desktop. 

The  user  has  control  of  VM/CMS  (virtual  machine/conversational 
monitor  system). 

The  whole  library  of  VM  software,  both  systems  software  and  applica- 
tions software,  is  available  for  immediate  use.  These  can  include  quite 
heavy  duty  applications. 
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With  the  VM  pass-through  facility,  XT/370  users  can  potentially  link 
into  many  other  VM  systems. 

However,  on  closer  inspection,  the  XT/370  as  it  exists  today  suffers  from 
profound  limitations. 

The  XT/370  is  not,  in  fact,  a  standalone  machine.  Current  chips  do  not 
provide  good  memory  management. 

Therefore,  while  CMS  is  on  the  XT/370,  VM  itself  still  must 
reside  on  the  host. 

As  new  chips  (like  the  286  or  386)  with  much  better  memory 
management  are  available,  it  could  become  possible  to  have  a 
self-contained  XT/370. 

Similarly,  coping  with  VM/CMS  takes  up  most  of  the  power  and  space 
in  the  XT/370. 

There  is  little  room  left  for  applications.  When  applications 
were  put  experimentally  on  the  XT/370,  performance  was  found 
to  be  quite  marginal  and  usually  unfeasible. 

However,  the  XT/370  does  have  sufficient  resources  to  serve  the 
purpose  outlined  for  it  in  IBM's  initial  announcement— a  pro- 
grammer's workstation.  Functioning  in  this  manner,  the  XT/370 
is  not  overloaded  and  can  provide  predictable  response  time. 

Apart  from  technical  limitations  (which,  after  all,  can  be  solved  by  applying 
more  hardware  resources),  there  is  the  larger  issue  of  whether  host-developed 
applications  should  be  (or,  in  some  cases,  can  be)  put  on  a  desktop. 
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"User  friendly"  is  an  overworked  word  but  one  that  should  be  taken 
seriously  when  considering  placing  micro-based  applications  In  user 
hands.  Annong  the  mounting  criticisms  of  host-based  systems  in 
general  are  that  they  are  difficult  to: 

Learn. 

Use. 

Adapt. 

Control. 

Moving  such  unchanged  applications  out  of  the  protective  environment 
of  the  data  processing  professional  and  onto  the  desktop  helps  neither 
the  end  user  nor  IS. 

Host-oriented  applications  are  not  by  nature  susceptible  to  minor 
"tweaking"  to  make  them  suddenly  user  friendly. 

Most  host  applications  assume  large  data  bases,  intricate 
processing  logic,  and  a  web  of  supporting  systems  software. 
Response  time  is  something  that  is  spread  out  between  many 
dozens,  if  not  thousands,  of  users. 

This  maps  poorly  against  the  micro's  strengths  of  having  con- 
siderable amounts  of  processing  power  focused  on  relatively 
small  amounts  of  data  in  order  to  provide  exceptional  response. 

•        A  considerable  number  of  organizations  (corporations  as  well  as  vendors)  do 
not  fully  appreciate  these  factors. 
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Several  corporations  INPUT  interviewed  plan  to  use  XT/370s  in  appli- 
cation settings. 

Two  mainframe  applications  vendors  have  planned  to  put  parts  of  their 
mainframe  product  onto  the  XT/370  as  a  way  to  get  an  "instant"  micro 
product.  One  of  these  vendors  attempting  an  instant  product  has 
already  run  into  serious  difficulties  because  of  the  capacity  problems 
described  above.  (On  the  other  hand,  there  are  vendors  like  Informa- 
tion Builders,  which  rewrote  FOCUS  for  the  IBM  PC.) 

However,  as  first  mentioned,  the  concept  of  the  XT/370  fills  many  of  the 
requirements  for  a  true  M-M  system,  including: 

High  power. 

Host  connectivity  (i.e.,  VM  pass-through). 
Shared  operating  system  environment. 
Data  sharing. 

Potentially,  applications  and  application  program  segmentation. 

The  promise  of  the  XT/370  concept  will  be  seen  in  later  generations  (the 
XT/3000?)  and  will  have  the  capacity  to  do  larger  amounts  of  useful  (i.e., 
applications)  work.  However,  that  will  be  only  the  first  step. 

It  will  be  equally  important,  if  not  more  so,  to  think  through  how 
applications  logic  and  data  should  be  distributed  throughout  the  nodal 
network. 

When  this  is  done,  it  will  represent  a  successful  implementation  of  the 
early  efforts  of  remote  computing  service  (RCS)  companies  to  dis- 
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tribute  pieces  of  their  applications  onto  micros.  (The  RCS  firms'  lack 
of  success  was  caused  by  both  technical  limitations  and  commercially 
derived  inhibitions  against  placing  too  much  functionality  in  the  micro.) 

Information  Center  activities  would  be  a  logical  initial  candidate,  since 
solutions  would  be  generalizable  and  under  the  control  of  IS. 

Applications  segmentation  would  have  to  be  approached  much  more 
carefully  because  of  the  increased  time,  expense,  and  coordination 
involved. 

Both  IS  and  vendor  respondents  see  the  XT/370  playing  at  least  a  moderate 
role  in  the  future,  as  shown  in  Exhibit  V-l. 

INPUT  knows  that  some  of  these  positive  assessments  are  based  on  a 
misunderstanding  of  the  XT/370's  current  capabilities. 

Consequently,  IS  management  should  be  very  careful  in  verifying  any 
claims  regarding  the  application  virtues  of  the  XT/370  as  it  now  exists. 

UNIX 

It  is  beyond  the  scope  of  this  report  to  fully  assess  the  current  and  future 
claims  being  made  concerning  UNIX.  (For  additional  analysis,  see  INPUT'S 
Executive  Bulletin,  An  Unusually  Noteworthy  Introduction  of  a  Xenolith. 
However,  the  following  facts  should  be  kept  in  mind: 

It  is  true  that  considerable  percentage  growth  is  being  planned  for 
UNIX-based  micro  hardware;  however,  this  is  starting  from  a  very  low 
base  (0.1%)  currently  and  will  reach  only  1.0%  in  1986,  among  the 
INPUT  respondents. 
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EXHIBIT  V-1 


FUTURE  IMPORTANCE  OF  XT/370  TO  SELECTED  GROUPS 
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Planning  New  Micro- 
Mainframe  Applications 
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*  Future  Use 
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Most  IS  respondents  saw  UNIX  as  even  less  important  than  the  XT/370 
In  their  future  plans,  as  shown  in  Exhibit  V-2. 


The  plethora  of  UNIX-like  systenns  will  discourage  major  software 
vendors  from  developing  UNIX-based  applications. 

It  is  true  that  UNIX's  portability  and  ability  to  network  between  machines 
makes  it  appealing  as  a  potential  M-M  vehicle. 

However,  this  potential  is  largely  untested  in  a  corporate  environment; 
much  of  the  academic  and  scientific  experience  with  UNIX  is  not 
pertinent  for  major  business  users.  (See  INPUT'S  1983  report  Selecting 
User  Friendly  Operating  Systems  for  Personal  Computers.) 

Most  importantly  and  for  some  time  to  come,  micro  applications  will 
have  to  link  into  conventional  MVS  or  CMS  systems.  UNIX  will  have  no 
more  advantage  than  any  other  micro-based  environment. 

DATA  SYNCHRONIZATION 

Data  synchronization  and  data  security  issues  generally  are  dealt  with  in  more 
detail  in  this  study's  companion  report,  Micro-Mainframe;  Communications 
Issues. 

However,  the  special  case  of  synchronization,  as  shown  in  Exhibit  V-3, 
directly  impacts  M-M  system  design  and  user  feasibility  issues.  The  facts  as 
they  stand  are: 

Data  synchronization  of  updates  on  a  real-time  basis  between  an  inde- 
pendently processing  mainframe  and  a  micro  is  not  feasible  now. 

Potentially,  one  or  more  of  the  relational  DBMS  vendors  may  find  a 
solution  to  the  concurrency,  multiple-update,  and  lockout  problems. 
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EXHIBIT  V-2 


XT/370  AND  UNIX: 
FUTURE  IMPORTANCE  AND  CURRENT  UNDERSTANDING 
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Even  if  this  is  accomplished,  these  solutions  in  their  initial  versions  will 
be  both  slow  and  inefficient.  Thus,  it  is  assunned  that  there  cannot  be 
any  routine  solution  for  these  problems  for  some  time  to  come. 

Consequently,  the  expressed  desire  for  truly  Interactive  M-M  applica- 
tions probably  cannot  be  satisfied  for  several  years,  at  best. 

•  However,  on-line  batch  solutions  may  be  acceptable  in  many  situations.  These 
are  discussed  at  greater  length  in  the  next  chapter. 

B.       PLANNING  ISSUES 

•  In  planning  for  M-M  applications,  planners  must  judge  how  M-M  performs 
relative  to  traditional  mainframe-based— as  well  as  micro-based— systems, 
using  a  number  of  criteria,  including: 

Data  linkage  across  applications. 

Application  transparency. 

Environmental  adaptability. 

Potential  for  central  control. 

Flexibility  in  meeting  user  needs. 

Stability. 

Data  synchronization. 
Operation  economy. 
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operation  speed. 


Implementation  speed. 

Data  linkage:  Although  DBMSs  were  originally  conceived  to  unite  data  across 
applications,  in  practice  it  has  often  proved  infeasible  to  do  so  because  of 
complexity,  control,  and  flexibility  problems.  These  problems  are  worse  in 
micros  because  of  the  relatively  limited  hardware  and  software  environments. 

At  present,  of  course,  linkages  across  M-M  applications  are  not  tech- 
nically possible  in  a  real-time  environment. 

On  a  batch  basis  they  are  only  feasible  where  micro  applications  are 
treated  as  intelligent  terminals  feeding  transactions  to  the  mainframe 
system. 

Application  transparency;  This  is  the  extent  to  which  an  application  can  be 
understood  or  comprehended,  from  both  the  user  level  and  a  technical  level. 

Many  host-based  applications,  because  of  their  size  and  complexity,  are 
rather  opaque. 

On  the  other  hand,  micro-based  systems—being  smaller  and  closer  to 
the  end  user—are  much  more  comprehensible. 

M-M  applications  have  the  potential  danger  of  adding  yet  another  layer 
of  complexity  to  host  systems.  To  the  extent  that  the  host  "system"  is 
largely  a  data  repository,  this  danger  can  be  alleviated  by  placing  as 
many  logical  and  processing  functions  as  possible  at  the  micro  level. 

Environmental  adaptability;  This  is  the  extent  to  which  physical  environments 
can  be  changed  (e.g.,  adding  terminals  to  SNA  systems)  or  an  application  can 
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be  moved  to  a  new  hardware  or  systems  software  environment.  Host-based 
systems  are  adequate  but  clumsy  in  this  regard.  Micro  systems  are  more 
hardware-bound. 

Potentially,  UNIX-based  systems  allow  an  evolutionary  path  for  both 
micro  and  M-M  applications. 

However,  UNIX  is  quite  large  (around  nine  megabytes)  and  is  still 
essentially  an  unknown  quantity  in  regard  to  commercial  applications. 
The  very  profusion  of  UNIX  variants  makes  any  claim  for  universality  a 
hollow  one  at  this  stage.  (See  the  previous  section  on  UNIX.) 

Otherwise,  M-M  applications  would  be  even  more  environment-bound 
than  their  mainframe  cousins. 

Potential  for  central  control;  Here  host-based  systems  are  obviously  much 
superior  to  micro  applications.  M-M  applications  are  at  an  intermediate 
point. 

User  flexibility:  Mainframe  systems  are  notorious  for  their  inflexibility  (at 
least  in  user  eyes),  and  micro  systems  (fairly  or  unfairly)  are  considered 
unbeatable.  Depending  on  how  tightly  coupled  to  the  host  an  M-M  application 
is,  it  could  be  closer  to  a  standalone  micro  system  or  as  bad  as  (or  worse  than) 
a  mainframe  system.  (Micro  applications  written  in  assembler  language  are, 
of  course,  another  problem  altogether.) 

Stability:  This  is  meant  the  extent  to  which  an  application's  operations  are 
error-  and  failure-free.  While  mainframe  applications  still  have  a  long  way  to 
go,  there  are  many  facilities  built  into  the  hardware  and  software  environ- 
ment to  assist  in  maintaining  operations.  Micro  systems  by  nature  are  con- 
siderably more  fragile,  being  without  the  supporting  infrastructure  one  is 
accustomed  to  seeing  in  mainframe  systems  (e.g.,  audit  tools). 
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Data  synchronization;  Here  the  situation  is  very  similar  to  the  "stability" 
area  above.  This  leaves  out  the  current  unsolved  problem  of  synchronizing 
data  in  an  interactive  M-M  environment. 

Operation  economy  and  operation  speed;  Both  micro  and  M-M  applications 
can  potentially  be  much  better  or  worse  than  their  mainframe  equivalents. 

Implementation  speed;  Although  large,  complex  mainframe  systems  often 
take  years  to  implement,  an  M-M  system  that  was  implemented  like  a  main- 
frame system  would  be  worse.  M-M  systems  that  have  more  in  common  with 
off-the-shelf  micro  applications  would  be  infinitely  superior.  However, 
modifying  micro  packages  is  itself  an  undertaking  that  can  be  difficult  and 
frustrating. 

Exhibit  V-4  summarizes  the  performance  of  each  of  the  three  implementation 
approaches  and  gives  them  a  "grade"  for  each  factor. 

There  is  no  obvious  choice  at  present  between  the  three  alternatives; 
all  have  their  strong  and  weak  points. 

The  path  selected  should  be  one  that  maps  best  against  the  corporate 
environment,  IS  capability,  and  application  needs. 

M-M  applications  have  the  greatest  scope  for  improvement.  At  least 
potentially,  M-M  applications  could  be  superior  to  either  of  their 
parents. 
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EXHIBIT  V-ii 


ADEQUACY  OF  SYSTEM  IMPLEMENTATION  APPROACHES 


RATINGS  OF  1 

MPLEMENTATION  APPROACHES 

CRITERIA 

TRADITIONAL 
MAINFRAME-BASED 

MICRO-BASED 

M 1  PR  n / 

IVII     r\ / 

MAINFRAME-BASED 

Data  Linkage  Across 
Applications 

C- 

D 

D- 

Application 
Transparency 

C 

A 

B  to  D 

Environmental 
Adaptability 

C 

D* 

D* 

Potential  for  Central 
Control 

B 

F 

C 

Flexibility  in  Meeting 
User  Needs 

c- 

A 

B  to  D 

Stability 

c+ 

D* 

D* 

Data  Synchronization 

c^ 

D 

D 

Operation  Economy 

c 

A  to  D 

B  to  D 

Operation  Speed 

B 

A  to  F 

A  to  D 

Implementation  Speed 

D 

A 

A  to  D- 

Key:   A  =  Meets  criteria  best 

F  =  Does  not  meet  criteria 
*  Potential  for  one  or  more  grade  improvement 
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RECOMMENDATIONS 


VI  RECOMAAENDATIONS 


•  These  recommendations  are  divided  into  three  categories: 

Technical  approaches. 
End-user  relationship  building. 
Vendor  partnerships. 

A.       TECHNICAL  APPROACHES 

I.       LOW  RISK:  DATA  DOWNLOADING 
a.        An  Entry  Strategy 

•  IS  should  select  an  important,  but  technically  unambitious,  user  area  that: 

Uses  a  significant  number  of  standalone  PCs. 
Rekeys  corporate  data. 

Uses  data  from  a  software  vendor  product  that  has  a  proprietary  down- 
loader. 
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IS  should  ascertain  that  the  department  has  at  least  a  moderate  amount  of 
interest  and  commitment  to  downloading  data. 

If  all  these  requirements  are  met,  then  IS  should: 

Analyze  the  data  needed. 

Provide  an  extract  file. 

Set  up  inquiry  and/or  scheduled  downloading. 

At  every  step,  IS  should  carefully  explain  what  is  and  is  not  possible  using  this 
approach. 

This  approach  will  begin  serious  M-M  work  in  a  controlled  environment.  With 
successes  behind  it,  any  caution  that  IS  shows  toward  more  ambitious  and 
technically  demanding  M-M  projects  will  be  better  accepted. 

b.  Standards 

Ironically,  standard  setting,  if  done  too  early,  could  be  a  high-risk  alternative 
since  IS  departments  would  then  be  locked  into  obsolescent  technology. 

Since  there  are  currently  no  obvious  product  winners  from  a  technological 
standpoint  and  since  there  will  be  a  next  generation  of  products  soon,  the 
standard  setting  should  be  limited.  That  is: 

The  number  of  current  M-M  link  products  used  should  be  kept  at  a 
reasonable  number  (a  maximum,  say,  of  four  to  six). 

Where  there  is  a  significant  investment  in  proprietary  software  (e.g., 
from  MSA,  Cullinet,  McCormack  &  Dodge),  that  vendor's  link  package 
should  be  used  if  there  is  user  demand  for  that  data. 
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Implementations  should  be  relatively  inexpensive  and  reversible.  The 
more  an  application  is  bound  to  a  current  vendor's  technology  and  the 
more  important  the  application,  the  more  difficult  it  will  be  to  change 
direction.  (This  is,  of  course,  the  vendor's  objective.) 

c.       The  Information  Center  as  a  Connectivity  Tool 

in  many  people's  minds  the  Information  Center  has  gone  into  a  shadow  as  a 
result  of  the  advance  of  PCs.  It  may  also  be  eclipsed  by  M-M  linkages. 

Looking  back,  one  sees  that  much  of  the  problem  is  caused  by  the  relatively 
low  level  of  support  and  user  friendliness  in  many  Information  Centers. 
Partly,  this  was  a  historical  accident  in  that  many  Information  Centers  were 
established  at  the  start  of  the  recent  recession,  and  they  were  starved  for 
funds. 

At  least  as  an  interim  step,  the  Information  Center  has  a  role  to  play  as  a 
staging  area  for  extracted  files  that  can  be  downloaded.  For  later  implemen- 
tation of  M-M  applications,  the  Information  Center  will  be  bypassed  where 
production  data  files  are  used. 

LOW/MEDIUM  RISK:  DEVELOPING  AN  ON-LINE  BATCH  STRATEGY 

IS  departments  developing  an  on-line  batch  strategy  must  steer  a  careful 
course. 

The  micro  must  be  sufficiently  isolated  from  the  host  system  so  that 
input  and  output  can  be  viewed  essentially  as  file  transfers.  This  is 
true  even  if  the  data  transfers  are  very  short  and  frequent~i.e.,  trans- 
actions, as  shown  in  Exhibit  Vi- 1. 
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EXHIBIT  VI-1 


ON-LINE  BATCH-DATA  TRANSFERS 
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On  the  other  hand,  if  the  micro  system  becomes  too  isolated,  essential 
central  coordination  and  control  is  absent. 

Exhibit  VI-2  shows  a  conceptual  micro  applications  post-processor  that 
would  be  interposed  between  the  micro  application  and  data  base,  and 
the  central  data  base. 

•  This  kind  of  post-processor  will  help  to  close  the  gap  that  will  arise  between 
processing  steps  at  the  micro  level  that  are  recognized  as  host  transactions 
and  other  host  data  base  changes  that  are  not  normally  host  system  trans- 
actions. 

•  Developing  such  interface  procedures  will  be  necessary  in  order  to  meet  the 
"next-generation"  M-M  applications  described  in  the  case  studies  in  Chapter 
III. 

3.       HIGH  RISK:  INTERACTIVE  APPLICATIONS 

•  Interactive  applications  may  become  feasible,  at  least  on  an  experimental 
basis,  in  the  medium  term  (three  to  five  years),  although  it  will  almost 
certainly  be  much  longer  before  interactive  applications  are  routinely  used. 

•  Section  C  of  this  chapter  describes  strategies  for  working  with  vendors.  Such 
partnerships  would  reduce  the  risk  and  allow  for  sooner  implementation  of 
interactive  applications. 

B.       ENCMJSER  RELATIONSHIP  BUILDING 

•  Because  of  the  nature  of  M-M  applications,  much  of  the  activity  will  have  to 
take  place  at  user  locations.  This  makes  the  quality  of  the  relationship 
between  end  users  and  IS  important.     Executive-level  relationships  will 
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EXHIBIT  VI-2 


DATA  BASE  POST-PROCESSOR:    LIMITS  EXCESSIVE  MICRO  INDEPENDENCE 


Micro  Application  Logic 


Data  Element  Changes 


Local 

Data 

Base 


Prior  Version 
of  Local  Data 
Base  (After 
Update  From 
Central  Data 
Base) 


Post- 
Processor  1  : 
Key  Data 
Element 
Comparison 


Data 
Changes 


Post- 
Processor  2: 
Transaction 
Generator 


Control  / 
Balance 
Analysis  and 
Report 


T  ransactions 
to  Central 
Data  Base 


A    =  Data  Elements  Common  to  Host  and  Local  Data  Bases  (Key  Data  Elements) 
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generally  be  even  more  important.  The  areas  that  should  receive  focus 
include:  . 

Improving  relationships  generally. 

Improving  PC-related  services. 

Changing  the  IS  organization. 

GENERAL  I.S.-USER  RELATIONSHIP  IMPROVEMENTS 

It  is  beyond  the  scope  of  this  report  to  review  all  the  things  that  could  be  done 
to  improve  IS-user  relationships. 

Most  of  the  findings  and  recommendations  in  INPUT'S  1982  report, 
Evaluating  the  EDP  Level  of  Service,  are  still  valid  (and  unfortunately 
are  needed  in  almost  as  many  organizations  as  before). 

Several  key  points  from  the  earlier  report  are  reprinted  here  in 
Appendix  D  for  readers'  convenience. 

It  is  especially  important  that  end  users  have  confidence  in  IS's  good  inten- 
tions and  knowledge  when  IS  provides  advice  on  M-M  issues.  Policies  to 
achieve  this  include: 

Regular  meetings  with  key  user  staff. 

Frankness  on  issues  and  problems;  unnecessary  jargon  should  be 
avoided. 

Semi -technical  briefings  on  IS  issues  in  general  and  M-M  issues  in 
particular. 
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A  "marketing"  approach  to  IS  service  by  IS  (complete  with  "marketing 
reps"  if  resources  are  available). 


Keeping  a  "book"  on  key  operations  units  to  understand  what  motivates 
their  systems  requirements.  Business  planning  documents  are  useful, 
but  personal  contact  is  even  more  useful. 

PC  SERVICES 

Much  existing  IS  PC  support  is  inadequate  in  terms  of  quality,  quantity,  and 
coverage.  However,  it  is  even  more  critical  now  to  provide  this  support  than 
it  was  in  the  past. 

PC  support  was  the  subject  of  a  1982  INPUT  study.  Supporting  Personal 
Computer  Software.  The  recommendations  given  in  that  study  are  still 
valid;  consequently,  all  the  attributes  of  PC  support  will  not  be  de- 
tailed here. 

A  summary  of  these  earlier  recommendations  is  contained  in  Appendix 
E. 

The  PC  support  function  is  more  important  than  before  for  two  reasons: 

The  more  that  users  (and  IS)  are  educated  on  the  true  capabilities  of 
micros,  the  less  likely  they  are  to  go  chasing  after  impossible  and/or 
dangerous  M-M  applications. 

The  PC  support  function,  reporting  to  IS,  can  provide  an  excellent  early 
warning  system  for  users'  M-M  intentions. 

IS  can  work  with  users  to  construct  M-M  systems  that  all  sides 
can  live  with. 
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At  the  least,  IS  has  more  time  to  head  off  poorly  considered 
initiatives,  mobilizing  countervailing  forces  if  need  be. 

ORGANIZATIONAL  CHANGES 

Many  IS  organizations  are  considering,  and  some  have  implemented,  a  partial 
or  full  decentralization  of  their  application-reloted  functions. 

At  the  least,  this  can  take  the  form  of  physical  decentralization,  with 
the  units  still  reporting  to  IS,  as  shown  in  Exhibit  VI-3. 

M-M  applications  can  add  another  dimension  to  this,  as  shown  in 
Exhibit  VI-4. 

Some  of  the  physically  decentralized  units  can  become  organiza- 
tionally decentralized  also. 

Corporations  may  wish  to  experiment  with  both  approaches  to 
see  which  works  best;  i.e.,  should  the  organization's  structure  be 
skewed  more  to  the  "micro"  or  to  the  "mainframe"? 

The  exact  arrangements  will  vary  depending  on  such  factors  as: 

The  corporate  culture. 

User-IS  relations. 

Amount  of  technical  complexity  of  systems  in  the  corporation. 
Size  of  decentralized  units. 

Amount  of  strategic  business  unit  (SBU)  application  inde- 
pendence. 

SBU  willingness/ability  to  manage  a  technical  function. 
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EXHIBIT  VI-3 


ORGANIZATIONAL  EVOLUTION  INTO  THE 
MICRO-MAINFRAME  ENVIRONMENT  (Phase  1) 
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ORGANIZATIONAL  EVOLUTION  INTO  THE 
MICRO-MAINFRAME  ENVIRONMENT  (Phase  2) 
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•  Ultimately,  the  IS-related  organization  could  evolve  into  something  similar  to 
that  in  Exhibit  VI-5. 

C.       VENDOR  PARTNERSHIPS 

•  One  of  the  findings  in  Chapter  III  was  that  the  adequacy  of  technical  M-M 
arrangements  is  one  of  the  chief  determinants  of  M-M  application  success. 

A  key  finding  in  Chapter  IV  was  that  interactive,  shared  functionality 
M-M  applications  were  a  goal  for  most  organizations. 

Unfortunately,  the  discussion  in  Chapter  V  indicated  that  this  sort  of 
application  will  not  be  technically  feasible  for  some  time  to  come. 

•  While  on-line  batch  systems  will  often  be  effective,  they  will  not  always 
satisfy  minimal  user  requirements  (for  example,  in  a  securities-  or  currency- 
trading  environment)  and  will  often  ultimately  leave  many  users  somewhat 
dissatisfied. 

•  Vendors  live  by  satisfying  users.  Consequently,  large  IS  organizations  would 
do  well  to  enter  into  cooperative  arrangements  with  one  or  more  vendors  to 
find  technical  M-M  solutions  that  work  in  a  real  organization. 

IS  would  contribute: 

A  test  bed. 

Machine  time. 

Business  and  systems  analysts. 
Technical  support  and  assistance. 
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EXHIBIT  VI-5 


ORGANIZATIONAL  EVOLUTION  INTO  THE 
MICRO-MAINFRAME  ENVIRONMENT 
(Phase  3) 


Central  Mainframes, 
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Senior  Technical  Experts 


Multi-Department  Systems 
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All  "owned"  application  system  functions  are  physically 
located  in  and  report  to  their  SBUs. 
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The  vendor(s)  would  contribute: 


Technical  expertise. 

Advice  on  workable/unworkable  alternatives. 

Product  prototypes. 

Corporations  could  stay  at  the  leading  edge  technically  while  solving  real 
business  problems.  There  would  have  to  be  some  limits  on  the  relationship. 

IS  (and  individual  staff  members)  would  have  to  adhere  to  reasonable 
vendor  requirements  to  maintain  security  on  what,  after  all,  could  be  a 
valuable  product. 

There  would  have  to  be  a  "no  raiding"  agreement  on  each  other's 
personnel. 

Both  small  and  large  vendors  have  their  attractions. 

Large  vendors  have  more  products  and  a  larger  market  share.  Often 
there  may  be  a  pre-existing  relationship  between  IS  and  a  vendor  to 
build  on. 

Smaller  vendors  may  be  more  innovative  and  "hungrier";  they  may, 
however,  be  almost  paranoid  about  secrecy. 

Research  partnerships  that  work  out  well  could  result  in  a  more  permanent 
business  arrangement,  including: 

Corporate  IS  playing  a  more  active  role  in  product  development. 

The  corporation  and/or  IS  taking  a  stake  in  promising  companies. 
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APPENDIX  A:   M  I  C R O - M A  I N F R A M E  USER 

QUESTIONNAIRE 


CATALOG  NO.  lUIEIPIMI  I  I  1 


MICRO-MAINFRAME  USER  QUESTIONNAIRE 


INPUT  is  conducting  a  study  on  the  issues  involved  in  linking  microcomputer 
host  systems  and  data.  We  will  make  recommendations  on  how  corporations  can 
best  deal  with  these  issues  in  the  coming  years.  We  would  like  your  organiza- 
tion to  take  part  in  this  study  by  describing  what  you  are  doing  now,  what 
your  plans  are  and  what  problems  you  see.  This  information  will  be  used  by 
IS  departments  in  their  planning  and  will  also  be  used  by  a  wide  variety  of 
information  service  vendors  to  offer  more  useful  products  and  services. 

None  of  the  information  that  you  provide  will  be  associated  with  your  company. 
In  return  for  your  taking  part  in  this  study,  we  will  send  you  a  summary  of 
this  study  on  its  completion  and  will  also  send  you  a  summary  of  INPUT'S 
report,  PC  Software  Support  in  Large  Corporations. 

1.      How  many  personal  computers  are  in  use  within  your  company?    (If  no 
PCs  are  used  or  planned  by  the  end  of  1985,  end  interview.) 

Now  End  of  1984  End  of  1985 

Total  all  types       


IBM  PC  XT/370  or  3270/PC 


IBM  PC  except  XT/ 370  or 

3270/PC  and  IBM  PC  SW /data- 
compatible  types 

UNIX-based  systems 

Other  personal  computer  types 

(Total  should  equal  sum  of  parts) 


2a.    How  will  the  UNIX-based  systems  be  used? 


2b.    In  the  future,  how  important  do  you  see  UNIX-based  systems  being  to 
your  organization's  plans?    (1  =  low  importance,  5  =  high  importance) 

UNIX-based  systems  __________ 

Why?  
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3a.    In  the  long  run,  how  important  do  you  see  the  XT/ 370  in  your  organiza- 
tion's plans?    (1  =  low  importance,  5  =  high  importance) 

XT/ 370   


Why? 


The  3270/PC? 


Why? 


3b.    How  well  would  you  rate  your  organization's  current  understanding  of  the 
capabilities  of  the  XT/ 370  and  the  3270/PC?    (1  =  low  degree  of  under- 
standing, 5  =  high  degree  of  understanding) 

XT/370    3270/PC   


Please  give  me  some  examples  of  particular  areas  where  your  organization 
requires  additional  information  on  the  capabilities  of  the  XT/370  and  the 
3270/PC.  (PROMPT  AS  NECESSARY:  for  example,  what  has  to  be  done  to 
permit  current  applications  software  to  run  on  the  XT/ 370,  how  will  concurrent 
data  bases  be  handled,  etc.) 

XT/ 370   


3270/PC 


4a.    How  many  multiuser  microcomputer  systems  (e.g..  Altos)  and  local  area 
networks  (LANs)  do  you  now  have  installed?    Who  are  the  vendors? 
What  are  these  systems  being  used  for? 

Multiuser  Micros  LAN 

Number  of  installations 


Vendors 


Applications /Uses 
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Hb.    How  many  multiuser  micros  and  local  area  networtcs  do  you  expect  to 
liave  installed  in  two  years?    Wliat  new  uses  will  you  have? 

Multiuser  Micros  LANs 

Number  of  installations  

Vendors    

Applications /Uses  '   '  '  '   


5.      In  the  future,  what  will  the  relative  importance  be  to  your  organization  of 
the  following  kinds  of  microcomputers?    (1  =  low  importance,  5  =  high 
importance)    Why?  (READ  EACH  ITEM  BELOW) 

Rating  Reason  Why 

Standalone  personal  computers     

running  personal  computer 

software?  (e.g.,  IBM  PC/XT)   


Standalone  personal  computers 
running  mainframe  software? 


Personal  computers  in  local 
area  networks? 


Mainframe  terminals  that  also 
have  personal  computer 
capabilities  (e.g.,  3270/PC) 
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6.      On  a  scale  of  1  to  5  with  1  representing  low  importance  and  5  representing 
higli  importance,  how  would  you  rate  the  following  functional  areas?  In 
two  years  how  would  your  importance  rating  change  for  these?    Why  the 
change? 


Spreadsheet  packages 
using  local  data 


Spreadsheet  packages 
using  downloaded  data 


Vendor  application 
packages  for  PCs 


In-house  developed 
programs  for  PCs 
(including  fourth 
generation  languages) 


7a.    The  next  set  of  questions  relate  to  so-called  micro-mainframe  application 
systems.    For  the  purposes  of  this  study,  we  are  defining  this  to  mean 
the  following:    "Applications  in  which  neither  the  mainframe  host  nor  a 
microcomputer  can  fully  carry  out  an  activity  without  utilizing  processing 
capabilities  or  data  from  the  other."  Do  you  agree  with  this  definition? 


Now 


Two 
Years 


Reason  for  Change 


7b.    If  no,  please  tell  me  how  you  would  modify  it: 
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8.      With  +5  representing  agreement  and  -5  representing  disagreement,  to 
what  extent  do  you  agree  that  "Within  three  to  five  years  most 
applications  that  are  now  host-based  will  have  a  considerable  amount 
of  functionality  taken  over  by  personal  computers  that  are  linked  to 

the  host." 


Why? 


9.  Do  you  believe  that  links  between  host  computers  and  micros  will  be 
predominantly  interactive,  predominately  on-line  batch,  or  about  the 
same?    (READ  DEFINITION  IF  NEEDED) 

DEFINITION:  ON-LINE  BATCH  -  where  the  micro  performs  processing 
on  a  standalone  basis  and,  periodically,  the  personal  computer  and  the 
host  exchange  data;  the  host  may  then  further  process  the  data  received. 

□  Predominantly  interactive 
Predominantly  on-line  batch 

□  About  the  same 

Reason  why  


10.    in  constructing  micro-mainframe  systems  how  common  do  you  think  each  of 
the  following  approaches  will  be?    (READ  LIST  BELOW)  Why?    (1  =  very 
common,  5  =  not  common)    NOTE:  ALL  OPTIONS  MAY  BE  RATED  "NOT 
COMMON"  OR  "VERY  COMMON"  -  OPTIONS  ARE  NOT  MUTUALLY  EXCLUSIVE. 

Rating  Reason  Why 

Modification  of  existing  software  _______ 


Use  existing  data  base  but 
write  new  application  code 


Write  entirely  new  applications 
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11a.  Generally,  to  what  extent  do  you  see  data  base  linkage  and  synchronization 
as  a  serious  problem  in  establishing  micro-mainframe  links?    (1  =  not  a 
problem,  5  =  a  serious  problem) 


lib.  How  serious  is  this  problem  for  systems  used  for  analysis?  (e.g., 
spreadsheets) 


11c.  How  serious  is  this  problem  for  production  systems?  (e.g.,  order  entry, 
payroll) 


lid.  What  can  an  organization  like  yours  do  to  solve  these  kinds  of  data  base 
linkage  and  synchronization  problems? 


12a.  Do  you  see  backup  and  security  as  significant  barriers  to  expanded  use 
of  linked  micro-mainframe  applications? 


Why? 


Why? 


If  no,  skip  to  question  13. 


12b.  What  are  the  major  problems  that  you  see? 


12c.  What  can  an  organization  like  yours  do  to  solve  these  problems? 


12d.  What  solutions  can  vendors  provide? 
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13a.  For  your  own  organization,  what  specific  applications  do  you  see  as  being 
the  most  suitable  as  micro-mainframe  applications?  (They  need  not  be 
computerized  applications  now.)    (Use  workspace  below.) 

13b.  Are  these  applications  planned  and  if  so,  at  what  stage  are  you 

in  implementing  them  (i.e.,  do  not  have  concrete  plans,  are  in  the 
planning  stage,  applications  are  being  developed,  applications  are  already 
implemented)?    (Use  workspace  below.) 


you  expect  to  develop  these  applications  in-house,  purchase  an  existing 
package  from  an  outside  vendor,  or  modify  in-house  an  existing  package? 
(Use  workspace  below.) 


Application 

Name 

Stage 

Source 

None 

Plan 

Dev. 

Imp. 

In-house 

Vendor 

Both 

1 . 

2. 





3. 

4. 

5. 

Comments 
1. 
2, 
3. 
4. 
5. 


14a.  Do  you  have  electronic  mail? 
If  no,  skip  to  question  15. 


J  Yes 


No 


14b.  How  many  users  currently  use  the  electronic  mail 
Now    Total  in  two  years 


14c.  On  the  average,  how  many  messages  are  now  sent  via  electrc 
month?    In  two  years? 

  Total  in  two  years  _________ 


per 


14d.  What  percentage  of  this  change  in  electronic  mail  use  do  yo! 
attributable  to  microcomputers?  o 


expect  to  be 
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15a.  In  what  ways  do  you  see  micro-mainframe  applications  increasing  your  data 
communications  requirements? 


15b.  In  what  ways  do  you  see  micro-mainframe  applications  decreasing  your  data 
communications  requirements? 


15c.  Overall,  do  you  think  that  the  net  effect  will  be  to  increase  or  decrease 
your  data  communications  requirements?    By  what  percent? 

Increase:  %       Decrease:  %       No  effect: 


16a.  With  1  representing  low  importance  and  5  representing  high  importance,  how 
important  will  it  be  for  your  company's  micros  to  communicate  with  micros 
in  other  departments? 


Why 


16b.  What  type  of  communication  facility  will  your  firm  be  likely  to  use  for  this 
type  of  communication?  (Use  matrix  on  following  page.) 


17a.  With  1  representing  low  importance  and  5  representing  high  importance, 
how  important  will  it  be  for  your  company's  micros  to  communicate  with 
mainframes  in  other  companies  (i.e.,  suppliers,  customer)? 

Why?  


17b.  What  types  of  communication  facilities  will  your  firm  be  likely  to  use  for 
this  type  of  communication?  (Use  workspace  on  following  page.) 
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18a.  With  1  representing  low  importance  and  5  representing  high  importance, 
how  important  will  it  be  for  your  company's  micros  to  communicate  with 
public  data  bases? 


Why? 


18b.  What  types  of  communication  facilities  will  your  firm  be  likely  to  use  for 
this  type  of  communication?  (Use  workspace  below.) 


Type  of 
Communication  Facility 

Micros  in 
Other  Departments 

Mainframes  in 
Other  Companies 

Public 
Data  Bases 

LAN 

Existing  network 

Leased  lines 

WATS 

Dial  up 

Public  data  network 

Other 

19a.  Do  you  expect  your  company's  micros  to  be  linked  to  more  than  one  type 
of  mainframe  (e.g.,  IBM  and  DEC)?  Q  Yes  No 
If  no,  skip  to  question  20. 

19b.  What  would  be  the  most  common  types  of  mainframe  linkages? 


19c.  Would,  typically,  the  same  micro  have  to  link  to  more  than  one  kind  of 
mainframe  at  different  times?        Yes  fj  No 
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20a.  Do  you  expect  that  your  company's  micros  will  have  to  be  linked  to  more  1 
than  one  type  teleprocessing  environment    (e.g.,  to  both  TSO  and  CMS,  or 
to  CICS  and  IMS  DOtQycs  Q  No 


If  yes: 
20b.  Which  ones? 


I 


20c.  Would,  typically  the  same  micro  have  to  link  to  more  than  one  kind  of 
software  environment  at  different  times?   [^Yes  |    |  No 

21a.  Do  you  expect  that  your  company's  micros  will  be  linked  to  more  than 
one  type  of  data  base  management  system    (e.g.,  to  both  IMS  and 
IDMS)?QYes  I    I  No 

If  yes: 
21b.  Which  ones? 


21c.  Would,  typically,  the  same  micro  have  to  link  to  more  than  one  kind  of 
DBMS  at  different  times?       Yes  |    |  No 

22a.  Do  you  expect  microcomputer  use  in  your  company  to  accelerate  the  

use  of  relational  data  base  systems  in  your  company?  [    |  Yes  |    [  No 

If  no,  skip  to  question  23. 
22b.  Which  one? 


22c.  Would  this  data  base  be  located  on  a  regular  mainframel    I   or  have  a 
special  machine^  devoted  to  it?    IF  SPECIAL  MACHINE:  Which  one? 


-  120  - 

©  1984  by  INPUT.  Reproduction  Prohibited. 


INPU 


CATALOG  NO. 


23a.  With  1  representing  no  assistance  and  5  representing  much  assistance, 
how  much  assistance  generally  do  you  expect  to  be  able  to  get  from 
vendors  in  helping  with  planning  and  implementing 
your  organization's  critical  micro-mainframe  applications? 


23b.  More  specifically,  how  would  you  rate: 

Vendor  Type  Rating  Reason  Why 
Microcomputer  hardware  vendors     


IBM 


Software  vendors  who  primarily 
offer  mainframe  software 


Software  vendors  who  offer  both 
mainframe  and  microcomputer 
software 


Remote  processing  (timesharing) 
vendors  (e.g.,  McAuto,  Boeing 
Computer  Services) 

Integrated  systems  (turnkey) 
vendors 


Professional  services  and 
consulting  firms 


24.    What  current  problems  do  you  see  micro-mainframe  systems  solving  or 
alleviating? 
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25a.  What  problems  do  you  see  being  created  or  aggravated  by  micro-mainframe 
systems? 


25b.  How  do  you  think  these  new  problems  should  be  dealt  with? 


THANK  YOU. 
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APPENOrX  B:         CORPORATE  RESPONDENT  PROFILE 


•  The  78  corporate  respondents  were  in  the  following  industrial  sectors: 

Process  Manufacturing!  26. 
Banking  and  Finance:  18. 
Discrete  Manufacturing:  16. 
Services:  II. 
Insurance:  7. 

•  Large  corporations  (i.e.,  revenues  of  over  $2  billion)  accounted  for  42  of  the 
respondents.  Smaller  organizations  (revenues  between  $500  nnillion  and  $2 
billion)  had  36  of  the  respondents. 

•  As  noted  in  the  body  of  the  report,  there  were  generally  few  respondent 
differences  that  correlated  with  industry  sector  or  company  size. 
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CATALOG  NO.  M^lPMl  I  I  I 


MICRO-MAINFRAME  VENDOR  QUESTIONNAIRE 


INPUT  is  conducting  a  study  on  the  Issues  involved  in  linking  microcomputer 
host  systems  and  data.    We  will  make  market  forecasts  on  related  products  and 
services.  We  would  like  your  organization  to  take  part  in  this  study  by 
describing  what  you  are  doing  now,  what  your  plans  are,  and  what  problems 
you  see.  This  information  will  be  used  by  IS  departments  in  their  planning 
also. 

None  of  the  information  that  you  provide  will  be  associated  with  your  company 
unless  you  wish  otherwise.    In  return  for  your  taking  part  in  this  study,  we 
will  send  you  a  summary  of  this  study  on  its  completion  and  will  also  send  you 
a  summary  of  INPUT'S  report,  PC  Software  Support  in  Large  Corporations. 


1.      Which  microcomputer  hardware  and  software  environments  in  the  following 
list  does  your  company  expect  to  be  important  for  micro-mainframe 
applications  in  1984  and  in  1986?  (1  =  low  importance,  5  =  high  importance) 
Why? 

End  of 

1984      1986  Reasons 
IBM  PC  AND  PC/XT     


IBM  XT/ 370 


IBM  3270/PC 


UNIX-based  products 


Other  micro  hardware      '  

(describe) 

Other  micro  software      

(describe) 

2.      What  do  you  see  as  the  major  opportunity  areas  in  connection  with  the 
XT/370  and  the  3270/PC? 

XT/370 


3270/PC 


What  do  you  see  as  limiting  the  growth  in  supplying  software  specifically 
aimed  at  the  XT/370  and  3270/PC? 
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3,      In  the  future,  what  will  the  relative  importance  be  of  the  following  kinds 
of  microcomputers?    (1  =  low  importance,  5  =  high  importance) 
Why?    (READ  EACH  ITEM  BELOW) 

Rating  Reason  Why 

Standalone  personal  computers 
running  personal  computer 

software?  (e.g.,  IBM  PC/XT)       __    '  


Standalone  personal  computers 
running  mainframe  software? 
(e.g.,  XT/370) 


Personal  computers  in  local 
area  networks? 


Mainframe  terminals  that  also 
have  personal  computer 
capabilities  (e.g.,  3270/PC) 


4.      On  a  scale  of  1  to  5  with  1  representing  low  importance  to  corporate  users 
and  5  representing  high  impKDrtance,  how  would  you  rate  the  following 
functional  areas?    In  two  years  how  would  your  importance  rating  change 
for  these?    Why  the  change? 

Two 

Now        Years  Reason  for  Change 

Spreadsheet  packages 

using  local  data       


Spreadsheet  packages 
using  downloaded  data 


Vendor  application 
packages  for  PCs 


In-house  developed 
programs  for  PCs 
(including  fourth- 
generation  languages)     
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5.      The  next  set  of  questions  relates  to  so-called  micro -ma  infra  me  application 
systems.  For  the  purposes  of  this  study,  we  are  defining  this  to  mean 
the  following:    "Applications  in  which  neither  the  mainframe  host  nor  a 
microcomputer  can  fully  carry  out  an  activity  without  utilizing  processing 
capabilities  or  data  from  the  other."    Do  you  agree  with  this  definition? 

CJ  Yes       n  No 

If  no,  please  tell  how  you  would  modify  it:  


6.      With  1  representing  agreement  and  5  representing  disagreement   to  what 
extent  do  you  agree  that  "Within  three  to  five  years  most  applications 
that  are  now  host-based  will  have  a  considerable  amount  of  functionality 
taken  over  by  personal  computers  that  are  linked  to  the  host?" 


Why? 


7a.  Do  you  believe  that  links  between  host  computers  and  micros  will  be 
predominantly  interactive,  predominantly  on-line  batch,  or  about  the 
same?    (READ  DEFINITION  IF  NEEDED) 

DEFINITION:  ON-LINE  BATCH  -  where  the  micro  performs  processing  on 

a  standalone  basis  and,  periodically,  the  personal  computer  and  the 

host  exchange  data;  the  host  may  then  further  process  the  data  received. 

CZl  Predominantly  interactive 

CU  Predominantly  on-line  batch 

CH  About  the  same 

Reason  why:     


7b.    How  is  your  firm  addressing  this  issue? 


7c.    How  does  this  compare  to  other  specific  products? 
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8a.    In  constructing  micro-mainframe  systems  how  common  do  you  think  each 
of  the  following  approaches  will  be?  (READ  LIST  BELOW)  Why?  (1  =  very 
common,  5  =  not  common)    NOTE:    ALL  OPTIONS  MAY  BE  RATED  "NOT 
COMMON"  OR  "VERY  COMMON"  -  OPTIONS  ARE  NOT  MUTUALLY 
EXCLUSIVE. 


Rating  Reason  Why 


Modification  of  existing 
software 


Use  existing  data  base  but 
write  new  application  code 


Write  entirely  new 
applications 


8b.    How  is  your  firm  addressing  this  issue? 


8c.    How  does  this  compare  to  other  specific  products? 


9a.    Generally,  to  what  extent  do  you  see  data  base  linkage  and  synchronization 
as  a  serious  problem  in  establishing  micro-mainframe  links?    (1  =  not  a 
problem,  5  =  a  serious  problem) 


9b.    How  serious  is  this  problem  for  systems  used  for  analysis  (e.g., 
spreadsheets)  ? 

Why?  


9c.    How  serious  is  this  problem  for  production  systems  (e.g.,  order  entry,, 
payroll)  ? 


Why 


9d.    What  do  you  see  as  the  general  solution  to  this  problem? 
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9e.    How  are  you  addressing  It? 


10a.  Do  you  see  backup  and  security  as  significant  barriers  to  expanded 
use  of  linked  micro-mainframe  applications? 

□  ycs  □  No       If  no,  skip  to  question  13. 

What  are  the  major  problems  that  you  see? 


10b. 

What  do 

you 

see  as  the 

general  solutions  to  these  problems? 

10c. 

How  are 

you 

addressing 

it? 
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11a.  What  specific  applications  do  you  see  as  being  the  most  suitable  as  micro- 
mainframe applications?    (They  need  not  be  computerized  applications  now.) 
(Use  workspace  below.) 

lib.  Are  products  for  these  applications  planned,  and^  if  so,  at  what  stage  are 
you  in  implementing  them  (i.e.,  do  not  have  concrete  plans,  are  in  the 
planning  stage,  applications  are  being  developed,  applications  are  already 
implemented)?    (Use  workspace  below.) 


11c.  Do  you  expect  users  to  develop  these  applications  in-house,  purchase  an 
existing  package  from  an  outside  vendor,  or  modify  in-house  an  existing 
package?    (Use  workspace  below.) 


Application  Name 

Stage 

Source 

None 

Plan 

Dev. 

Imp. 

1 n-house 

Vendor 

Both 

1. 

2. 

3. 

4. 

5. 

Comments: 


1  

2  

3   

4  ^  

5  

12a.  In  what  ways  do  you  see  micro-mainframe  applications  increasing  data 
communications  requirements? 


12b.  In  what  ways  do  you  see  micro-mainframe  applications  decreasing  data 
communications  requirements? 


12c.  Overall,  do  you  think  the  net  effect  will  be  to  increase  or  decrease 
data  communications  requirements?    By  what  percent? 

Increase:  %         Decrease:  %         No  effect: 


o 

o 
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13a.  With  1  representing  low  importance  and  5  representing  liigh  importance, 

how  important  will  it  be  for  a  company's  micros  to  communicate  with  micros 
In  other  departments? 


Why? 


13b.  What  type  of  communication  facility  will  a  firm  be  likely  to  use  for  this 
type  of  communication?   (Use  workspace  below.) 


14a.  With  1  representing  low  importance  and  5  representing  high  importance, 
how  important  will  it  be  for  a  company's  micros  to  communicate  with 
mainframes  in  other  companies  (i.e.,  suppliers,  customer)? 


lUb.  What  types  of  communication  facilities  will  a  firm  be  likely  to  use  for  this 
type  of  communication?  (Use  workspace  below.) 

15a.  With  1  representing  low  importance  and  5  representing  high  importance, 
how  important  will  it  be  for  a  company's  micros  to  communicate  with 
public  data  bases? 

Why?  


15b.  What  types  of  communication  facilities  will  a  firm  be  likely  to  use  for  this 

type  of  communication?  (Use  workspace  below.) 


 '  "  '•'^ 

Type  of 
Communication  Facility 

Micros  in 
Other  Departments 

Mainframes  in 
Other  Companies 

Public 
Data  Bases 

LAN 

Existing  network 

Leased  lines 

WATS 

Dial  up 

Public  data  network 

Other 
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16a.  Do  you  expect  a  company's  micros  to  be  linked  to  more  than  one  type  of 
mainframe  (e.g.,  IBM  and  DEC)? 

□  Yes  □  No       If  no,  skip  to  question  17. 

16b.  What  would  be  the  most  common  types  of  mainframe  linkages? 


16c.  Would,  typically,  the  same  micro  have  to  link  to  more  than  one  kind  of 
manframe  at  different  times? 

m  Yes  CH  No 

16d.  Which  of  your  products  will  facilitate  this?  ' 


17a.  Do  you  expect  that  a  company's  micros  will  be  linked  to  more  than  one 

type  teleprocessing  environment  (e.g.,  to  both  TSO  and  CMS,  or  to  CICS 
and  IMS  DC)? 

□  ves  □  No       If  yes: 

17b.  Which  ones? 


17c.  Would,  typically,  the  same  micro  have  to  link  to  more  than  one  kind  of 
software  environment  at  different  times? 

□  ves  □  No 

I7d.  Which  of  your  products  will  facilitate  this? 

18a.  Do  you  expect  that  a  company's  micros  will  be  linked  to  more  than  one 
type  of  data  base  management  system  (e.g.,  to  both  IMS  and  IDMS)  ? 

□  ves  □  No       If  yes: 
18b.  Which  ones? 


18c.  Would,  typically,  the  same  micro  have  to  link  to  more  than  one  kind  of 
DBMS  at  different  times? 

□  ves  □  No 

18d.  Which  of  your  products  will  facilitate  this? 
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19a.  Do  you  expect  microcomputer  use  In  a  company  to  accelerate  the  use  of 
relational  data  base  systems  in  a  company? 

□  ves  □  No      If  no,  skip  to  question  20. 


19b.  Whicli  one? 


19c.  Would  this  data  base  be  located  on  a  regular  mainframe  I    lor  have  a  special 
machine!    [devoted  to  it?    IF  SPECIAL  MACHINE:    Which  one? 


19d.  Which  of  your  products  will  facilitate  this? 


20a.  What  other  products  have  you  introduced  or  planned  to  introduce  that  will 
address  micro-mainframe  issues? 


20b.  What  functions  will  they  perform? 


20c.  What  hardware  and  software  environments  will  they  function  in? 


20d.  When  will  they  be  available? 


20e.  What  competitive  products  will  they  most  closely  compete  with? 
What  will  distinguish  your  product  from  the  competition? 


21.    What  current  problems  do  you  see  micro-mainframe  systems  solving  or 
alleviating? 
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22.    What  problems  do  you  see  being  created  or  aggravated  by  micro-mainframe 
systems? 


23.    How  do  you  think  these  new  problems  should  be  dealt  with? 


24.    Can  you  provide  technical  descriptive  material  about  the 
products  discussed? 


No 
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APPENDIX  D: 


EXCERPTS  FROM  INPUPS  REPORT.  EVALUATiNG  THE  EDP 
LEVEL  OF  SERVICE 


A.       GENERAL  RECOMMENDATIONS 

•  Chargeback  systems  should  be  viewed  as,  at  best,  a  cost-accounting  tool. 
Periodically,  such  data  should  be  used  as  an  input  to  determine  the  cost  of 
process  or  product. 

•  If  chargeback  systems  are  to  carry  out  this  limited  function,  the  costing 
mechanisms  must  be  greatly  expanded: 

All  costs,  not  just  hardware  costs,  should  be  tracked. 

Software  maintenance  costs,  especially,  should  be  tracked  by  project 
and  user.  This  is  rarely  done  now. 

Costs  should  be  based  on  resources  denied,  not  resources  consumed. 

•  IS  management  should  strongly  distrust  what  it  believes  user  satisfaction  to  be 
in  the  absence  of  objective,  rigorously  obtained  information. 

•  Surveys  and  other  attempts  by  IS  to  gain  such  knowledge  can  lead  to  frustra- 
tion by  both  IS  and  usersj 
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This  is  true  for  IS,  because  user  "satisfaction"  can  prove  to  be  elusive 
and  mercurial,  seemingly  reflecting  last  week's  triumph  or  crisis. 

Users,  on  the  other  hand,  can  view  such  well-meaning  surveys  as  goads 
that  remind  them  of  the  poor  service  they  believe  they  are  receiving. 

•  Similar  efforts  to  improve  communication  will  often  only  make  it  easier  for 
each  side  to  abuse  the  other. 

•  IS  should  resolve  these  and  a  number  of  related  problems,  by  recognizing  that 
user  expectations  and  IS  performance  should  be  linked.  Too  often  the  two 
exist,  at  best,  in  separate  vacuums  and,  all  too  often,  are  not  consciously 
examined. 

•  After  examining  current  practice  and  problems,  INPUT  believes  an  initiative 
that  would  usefully  serve  many  organizations  is  the  "user  contract,"  or  as 
INPUT  prefers  to  describe  it,  the  "user  service  agreement." 

•  User  agreements,  if  executed  successfully,  establish  common  standards 
against  which  performance  can  then  be  monitored. 

This  sets  up  the  dialogue  that  users  desire. 

IS  gets  its  chance  to  "educate"  users. 

Expectations  can  often  be  influenced  and  managed  by  IS. 

A  joint  measuring  process  is  established. 

Regular  reports  and  meetings  provide  early  warning  of  changing  needs 
and  objectives. 
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•        The  next  section  is  devoted  to  exploring  the  opportunities  inherent  in  service 
agreements. 


B. 


USER  SERVICE  AGREEMENTS 


There  are  four  aspects  to  implementing  user  service  agreements  ("i 


user 


contracts")  in  an  organization: 

Deciding  whether  service  agreements  are,  in  fact,  suitable  for  a 
particular  organization. 

Defining  the  agreements'  contents. 

Establishing  the  initial  service  agreements. 

Ensuring  that  IS  has  the  resources  to  support  the  process. 

•        Each  of  these  points  will  be  discussed  in  this  section. 


DECIDING  WHERE  SERVICE  AGREEMENTS  ARE  ADVISABLE 


Some  organizations  are  bad  bets  for  introducing  service  agreements. 
Examples  include  environments  where? 


Basic  corporate  policies  are  in  a  constant  state  of  flux. 


If  the  corporation  cannot  answer  the  question,  "Who  am  I?" 
then  users  in  particular  areas  will  have  similar  problems 
consistently  enunciating  their  needs. 
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IS  itself  will  also  be  buffeted  in  this  sort  of  environment  and  will 
find  it  difficult  to  live  up  to  its  commitments. 

User  management  turnover  is  high  and/or  user  management  is  not 
strong  or  very  political.  Agreements  cannot  be  built  on  sand. 

The  underlying  business  is  subject  to  marked  fluctuations  that  cannot 
be  predicted  or  influenced  by  the  organization.  "Reaction"  and  "catch- 
up ball"  are  the  watchwords.  Agreements  would  not  make  much  sense. 

•  This  does  not  mean  that  an  organization  must  be  rigid  and  unchanging  to 
benefit  from  service  agreements.  The  best  environment  is  one  that  is  growing 
and  dynamic. 

•  In  addition,  the  corporate  environment  should  be  receptive  to  planning  in 
general.  The  environment  would  be  very  favorable  if  past  planning  efforts 
resulted  in  bottom-line  benefits  that  are  widely  perceived  and  accepted. 

2.       FACTORS  DEPENDENT  ON  INFORMATION  SYSTEMS 

•  Some  of  the  critical  factors  for  making  service  agreements  work  are 
dependent  on  the  nature  and  capabilities  within  IS  itself.  It  makes  no  sense  to 
enter  into  agreements  that  IS  stands  little  chance  of  fulfilling. 

•  For  example,  some  "central"  or  "corporate"  IS  departments  ore  staff,  plan- 
ning, or  coordinative  groups.  They  often  do  not  have  either  the  detailed 
operational  knowledge  or  the  means  of  allocating  specific  operational  re- 
sources. This  kind  of  group  will  find  it  difficult  to  avoid  over-  or  under- 
committing  resources.  It  will  also  find  it  difficult  to  make  resource  re-alloca- 
tions. 

•  The  capabilities  of  IS  staff  and  computer  resources  must  be  candidly  assessed. 
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Some  IS  organizations  may  be  in  a  rebuilding  phase.  Taking  on  volun- 
tary commitments  that  would  result  in  more  failure  is  not  the  way  to 
nurse  the  patient  back  to  health. 

On  the  other  hand,  where  IS  management  is  new  and  has  succeeded  in 
making  internal  improvements,  service  agreements  are  a  way  of 
making  the  new  state  of  affairs  clear  to  the  outside  world. 

•  Finally,  there  are  some  specific  capabilities  that  will  be  required  to  make  the 
process  work: 

Project-  and  time-estimating  skills  will  be  important  for  IS  to  carry  out 
its  contractual  responsibilities.  An  adequate  system  should  be  in  place. 

Linked  with  estimating  skills  is  the  requirement  to  deal  with  perform- 
ance measurement  questions.  As  noted  earlier,  terminal  uptime  and 
response  time  are  two  of  the  most  critical  issues  involved. 

In  many  organizations,  these  measurements  are  performed 
incompletely  or  not  at  all. 

It  may  be  necessary  to  rely  on  user  personnel  for  some 
measurements  in  these  areas,  in  order  to  build  trust  and  com- 
munication. 

•  Exhibit  D-l  summarizes  the  effects  of  the  organizational  and  IS  factors  that 
affect  the  advisability  of  introducing  service  agreements. 

3.       USER-RELATED  FACTORS 

•  Service  contracts  will  not  serve  a  useful  purpose  if  relations  with  a  particular 
user  are  getting  worse  or  are  already  bad. 
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EXHIBIT  D-1 


ORGANIZATIONAL  AND  INFORMATION  SYSTEMS  FACTORS  AFFECTING 
ADVISABILITY  OF  INTRODUCING  SERVICE  AGREEMENTS 


FACTOR 

POSITIVE 
ELEMENT 

NEUTRAL 
ELEMENT 

NEGATIVE 
ELEMENT 

Corporate  Organization 

Dynamic 

Rigid 

Unstable 

Planning  Receptivity 

High 

Low 

Type  of  IS  Organization 

Centralized 

Decentralized 

Central 
Coordination 

IS  Personnel  Capabilities 

High 

Low 

IS  Top  Management  Time  in  Office 

Short 

Medium,  Long 

Hardware  Capacity 

Adequate 

Inadequate 

Telecommunications  Reliability 

High 

Low 

IS  Time  Estimating  Track  Record 

Reliable 

Unreliable 

IS  Performance  Measurement 
Capabilities 

High 

Low 
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There  is  a  minimum  level  of  trust  and  confidence  required  to  make 
such  agreements  work.  If  this  is  lacking,  trying  to  introduce  a  new, 
unfamiliar  issue  will,  at  least,  further  complicate  matters  and,  at 
worst,  make  the  user  think  IS  is  trying  to  divert  attention  from 
existing,  well-known  problems. 

However,  where  relations  are  improving,  even  if  they  still  are  not  very 
good,  a  service  agreement  can  be  further  evidence  of  IS's  commitment 
to  improvement.  z 

There  can  sometimes  be  a  thin  line  between  these  two  situations,  and  it 
can  be  useful  to  initially  introduce  an  intermediary  (from  either  inside 
or  outside  the  firm)  to  assess  the  situation  objectively. 

•        It  is  important  that  key  users  be  distinguished  from  the  average  and  limited 
users. 

It  is  the  key  users  who  usually  determine  whether  data  processing  will 
be  successful  in  an  organization  and  how  much  the  use  of  the  computer 
will  contribute  to  the  firm. 

Key  users  are  identified  by  a  combination  of: 

The  importance  of  the  user  department  to  the  organization. 

The  proportion  of  IS  resources  (human  and  hardware)  that  the 
user  department  consumes. 

Exhibit  D-2  illustrates  graphically  the  relationships  between  the  three 
types  of  users—key  users,  average  users,  and  limited  users. 

Generally,  where  a  department  consumes  significant  systems 
resources  and/or  the  department  is  important  to  the  company, 
the  department  will  be  a  key  user. 
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EXHIBIT  D-2 


DISTINGUISHING  KEY  USERS  FROM  OTHER  USERS 
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Note,  however,  that  where  there  is  a  pairing  of  extremes  (high 
consumption—low  departmental  importance,  or  vice-versa),  the 
department  is  probably  not  a  key  user. 

Some  IS  organizations  may  find  that  they  in  fact  have  few  key 
users:  their  biggest  customers  are  not  very  important  in  the 
totality  of  the  organization.  Missionary  work,  which  may  or 
may  not  involve  service  agreements,  would  certainly  be  indi- 
cated. 

Knowledgeable,  sophisticated  users  are  certainly  good  candidates  for  user 
contracts. 

Many  of  the  definitional  and  expectation  problems  caused  by  more 
naive  users  will  be  absent. 

This  kind  of  user  often  is  also  more  involved  with  the  IS  department 
and  data  processing  operations. 

Of  course,  they  cannot  be  ignored  so  easily  when  things  go  wrong. 

Where  users  are  increasing  their  use  of  services  not  supplied  by  IS,  this  can  be 
a  sign  that  a  service  agreement  is  needed  so  they  receive  the  services  they 
need. 

Sometimes  users  go  outside  for  services  that  IS  cannot  supply  at  all 
(e.g.,  certain  external  information  data  bases)  or  that  IS  cannot  do 
feasibly  (e.g.,  a  personal  computer  on  every  analyst's  desk). 

However,  sometimes  users  look  elsewhere  because  they  believe,  rightly 
or  wrongly,  that  IS  cannot  meet  their  needs.  Drawing  up  an  agreement 
with  the  user  will,  at  the  least,  identify  whether  this  is  so. 
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Finally,  current  user  satisfaction  as  perceived  by  IS  should  not  be  a  factor  in 
deciding  whether  to  establish  service  agreements.  As  shown  earlier,  IS  is 
more  likely  to  be  wrong  than  right  in  this  assessment. 

Exhibit  D-3  summarizes  the  effects  of  these  user-related  factors  that  would 
affect  the  advisability  of  introducing  service  agreements. 

SERVICE  AGREEMENT  CONTENTS 

Service  agreements  should  focus  on  essentials.  The  following  is  not  required: 
Complexity. 
Undue  formality. 
Legalisms. 
Rigidity. 

Service  agreements  could  become  extremely  large,  if  every  element  of  IS-user 
relationships  were  defined.  In  many  cases  this  is  not  necessary.  Where 
routine  operations  (e.g.,  batch  financial  systems)  have  been  operating 
smoothly  for  many  years,  the  adage  "if  it  ain't  broke,  don't  fix  it"  should  be 
followed. 

The  areas  that  should  be  focused  on  are  those  areas  that  are  new,  critical, 
and/or  have  a  significant  problem  potential.  INPUT'S  research  indicates  that 
for  many  IS  departments  the  critical  areas  will  be: 

Terminal  downtime. 

Response  time. 

Program  development  requests. 
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EXHIBST  D-3 


USER-RELATED  FACTORS  AFFECTING 
ADVISABILITY  OF  INTRODUCING  SERVICE  AGREEMENTS 


FACTOR 
(Separate  for  Each  User) 

POSITIVE 

ELEMENT 

NEUTRAL 
ELEMENT 

NEGATIVE 
ELEMENT 

Relations  with  User 

Moderate; 
Bad,  But 
Improving 

Excellent 

Moderate  S 
Worsening; 
Bad 

Amount  of  Outside  Services  Used 

Increasing 

Stable; 
Decreasing 

User  Sophistication 

High 

Low ; 
Medium 

Importance  of  EDP  to  User 

High 

Low 

Proportion  of  IS  Resources  Used 

High 

Low ; 
Medium 

Amount  of  User  Involvement 

High 

Low ; 
Medium 

User  Satisfaction  as  Perceived  by  IS 

Low, 

Medium , 
High 
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The  exact  issues  to  be  dealt  with  will  naturally  vary  from  user  to  user, 
depending  on  user  needs  and  the  status  of  the  application.  However,  there 
will  be  certain  points  that  should  at  least  be  considered  In  every  case. 
Exhibits  D-4,  D-5,  and  D-6  are  checklists  of  items  that  should  be  considered 
for  inclusion  in  every  agreement. 

User  agreements  should  be  viewed  as  flexible,  open-ended  documents  with 
provision  for  modification  by  either  side,  based  on  changing  conditions. 

Again,  a  legalistic  or  buyer-seller  state  of  mind  should  be  avoided. 

It  is  important  that  both  sides  be  able  to  give  as  much  warning  as 
possible  to  the  other  when  adverse  conditions  threaten.  Otherwise,  the 
tendency  will  be  to  hope  for  the  best  and  postpone  bad  news  as  long  as 
possible. 

This  raises  a  related  question  of  whether  chargeback  rates  should  be  included 
in  the  agreement. 

One  of  the  main  advantages  to  using  the  term  "service  agreement"  is  avoiding 
the  word  "contracts,"  which  implies  a  buyer-seller  relationship. 

Most  IS  operations  are  not  set  up  in  such  a  way  that  real  money  (or 
even  reliable  pseudo-money)  changes  hands. 

As  indicated  earlier,  most  chargeback  systems  are,  at  best,  accounting 
conventions.  Unless  the  chargeback  system  is  thought  through  at  least 
as  well  as  the  user  agreement  is,  it  would  be  a  mistake  to  associate  the 
two  in  one  package. 

If  charges  are  not  included  in  the  agreement,  then  what  does  IS  get  out  of  the 
agreement?  Are  promises  being  made,  with  nothing  received  in  return?  IS 
management  should  squarely  face  the  fact  that  they  are  an  internal  service 
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EXHIBIT  D-4 

SERVICE  AGREEMENT  CONTENT: 
TERMINAL  DOWNTIME  CHECKLIST 


• 

Definition,  i.e.,  by  type  of  malfunction 

-  - 

-    Local  hardware 

-    Communication  line 

-    Central  hardware 

-    System  software 

—     A nr)!ipatinn«?  c:nftwarp 

Uptime  requirements  by 

-    Time  period,  e.g.. 

•  Time  of  day 

•  Dav  of  week 

•  Season 

Location  (geography,  organization) 

-    Equipment  type 

6 

Malfunction  repair 

-    Responsibility,  by  type  of  malfunction 

-  Process 

-    Equipment  backup 

• 

Measurement  methodology,  e.g.. 

-    User  problem  logs           ■         ■     --^ ■ 

System  monitors 

Measurement  responsibilities 

-  Reporting 

-  Meetings 
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SERVICE  AGREEMENT  CONTENT: 
RESPONSE  TIME  CHECKLIST 


• 

Definition,  i.e., 

-  Minimum 

-  Maximum 

-  Average  (mean) 

-  Average  (median) 

-  Percentile  (e.g.  95th) 

• 

Requirements  by 

-  Time  of  day 

-  Time  period  (day  of  week,  month, 

season,  etc.) 

Location  (geography,  organization) 

-  Type  of  transaction 

• 

Priorities  by  type  of  requirement 

-    E.g.,  where  contention/degradation  occur 

• 

Measurement  methodology,  e.g., 

-  System  monitors 

-  On-site  stopwatch  sampling 

• 

Measurement  responsibilities 

-  Reporting 

-  Meetings 
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EXHIBIT  D-6 


SERVICE  AGREEMENT  CONTENT: 
PROGRAM  DEVELOPMENT  REQUEST  CHECKLIST 


•  Definition 

Levels  of  requests 

•  Process 

-  Forms 

-  Information 

:     -    Routing  to  be  followed 

•  User  responsibility 

-  Screening 

-  Prioritizing 

-  Batching  of  requests 

-  Benefit  assessment 

-  Benefit  measurement 

•  Cost /benefit  process 

-  When  to  be  applied 

-  Payback  criteria 

•  Feasibility  study  role 

-  Content 

-  Role  of  rapid  prototyping 

-  Turnaround 

•  Maintenance  "release"  cycle 

-  Time  period 

-  Exception  process 
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organization.  All  benefits  are  supposed  to  flow  in  one  direction,  hence: 
service  agreement. 

What  IS  management  receives  is: 

A  baseline  on  which  to  be  judged. 

A  measurement  process  agreed  to  by  key  users. 

A  standardized  process  for  being  informed  of  changes  in  user  activities. 
DEVELOPING  USER  SERVICE  AGREEMENTS 

In  most  organizations  there  will  be  little  initial  pressure  from  users  to  estab- 
lish data  processing  service  agreements.  As  indicated  in  the  study  findings, 
there  is  as  yet  little  user  awareness  of  the  concept. 

Consequently,  IS  can  introduce  user  service  agreements  in  a  cautious,  orderly 
process. 

Exhibit  D-7  shows  the  typical  steps  that  should  be  followed  in  devel- 
oping user  service  agreements. 

Most  of  the  steps  have  been  discussed  in  previous  sections: 

Make  sure  that  top  management  and  user  managers  understand  the 
concept.  It  is  important  not  to  use  the  word  "contract." 

Be  prepared  to  be  flexible  and,  within  reason,  to  modify  the  form  of 
agreements  to  meet  user  demands. 

Do  not  promise  more  than  can  be  delivered. 
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EXHIBIT  D-7 


STEPS  IN  DEVELOPING  USER  SERVICE  AGREEMENTS 


1.  Decide  whether  service  agreements  are  advisable  in  the 
organization's  environment. 

2.  Develop  and  tailor  a  concept  for  the  specific  organization. 

3.  Classify  users  into  key,  average,  and  limited-use  categories. 

4.  Discuss  concept  with  top  management,  key  users, 
and  selected  average  users. 

5.  Develop  draft  agreement  guidelines. 

6.  Negotiate  a  pilot  agreement  with  one  or  more  average 
users. 

7.  Revise  guidelines  after  pilot  is  in  place. 

8.  Circulate  revised  guidelines  to  key  users;  modify  as 
required. 

9.  Negotiate  agreements  with  key  users. 

10.  Negotiate  agreements  with  remaining  average  users 
after  arrangements  with  key  users  are  working 
satisfactorily. 

11.  Negotiate  agreements  with  limited  users  after  all  other 
agreements  are  in  place. 


-  151  - 


i1984by  INPUT.  Reproduction  Prohibited. 

ULOSUEP 


INPUT 


INFORMATION  SYSTEMS  RESOURCES  NEEDED 


Assuming  that  IS  has  made  the  correct  choice  in  deciding  to  implement 
service  agreements,  the  basic  resources  that  IS  needs  to  support  the  process 
will  be  in  place. 

However,  there  will  be  some  specialized  skills  and  tools  that  will  be  of  con- 
siderable assistance  in  making  service  agreements  work.  These  include: 

Cost  estimating.  ' 

Performance  measurement. 

Decision  support  systems. 

Rapid  prototyping. 
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APPENDIX  E:  EXCERPTS   FROM   INPUT'S  REPORT, 
SUPPORTING  PERSONAL   COMPUTER  SOFTWARE 


APPENDIX  E:         EXCERPTS  FROM  INPUPS  REPORT,  SUPPORTING 

PERSONAL  COMPUTER  SOFTWARE 


A.       ORGANIZATIONAL  SIZE  IS  A  HIDDEN  FACTOR  IN  THE  PC  SOFTWARE 
EXPERIENCE 

•  The  size  of  the  organization  is  an  often-overlooked  issue  in  PC  support.  The 
size  has  an  impact  on: 

The  number  of  PCs  supported. 

The  attitude  toward  using  outside  vendors  and  services. 

•  The  relative  strength  and  motivating  forces  of  PC  use  vary  by  organization 
size.  Users  acting  alone  are  most  significant  in  large  companies  because  they 
have  the  size  and  resources  to  vividly  affect  PC  campaigns.  Small  companies 
quite  often  go  it  alone  because  of  the  absence  of  central  IS  capability. 
User/vendor  combinations  are  most  prevalent  in  small  and  medium-sized 
companies,  and  the  similarity  in  size  of  vendor  and  user  organizations  provides 
an  acceptable  as  well  as  a  comfortable  working  relationship. 

•  Personal  computing  use  also  can  be  categorized  by  organization  size.  Smaller 
companies  often  look  to  vendors  for  assistance  in  implementing  customized 
systems.  Larger  companies  can  mobilize  resources  to  build,  maintain,  and 
replicate  systems  effective  for  all  applicable  PC  users,  while  in  medium-sized 
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companies  there  is  a  danger  that  custom  software  may  be  dependent  on  one 
person  to  operate  and  maintain  it. 

B.       CATEGORIES  OF  PC  SOFTWARE  SUPPORT 

•  Adequate  standard  setting  and  enforcement  provide  the  foundation  for  PC 
software  support. 

•  The  biggest  issue  for  PC  software  selection  is  whether  a  particular  application 
belongs  on  a  PC.  Alternatives  to  a  PC  include: 

An  information  center. 

A  mainframe  base. 

A  minicomputer-based  turnkey. 

A  manual. 

•  The  most  important  contribution  to  effective  use  of  PC  software  is  education 
and  training.  Unfortunately  it  is  the  most  neglected.  Good  documentation  is 
also  neglected.  It  is  difficult  to  convince  users  to  document  their  custom 
programs,  especially  when  IS  systems  are  not  necessarily  good  examples. 

•  Problem  resolution  is  the  central  role  of  a  support  organization.  Too  often, 
however,  PC  software  support  is  equated  with  problem  resolution.  The  result 
is  a  support  function  relegated  to  "fire  fighting."  Problem  resolution  should 
be  the  backstop,  not  the  front  line,  of  PC  support. 
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THE  GREATER  THE  1.5.  RESOURCE.  THE  GREATER  THE  POTENTIAL 
BENEFIT 


•  There  are  four  levels  of  PC  software  support*  In  order  of  resource  and 
expertisej  they  ares   

The  foundation  level.      ^       r  .  ; 

The  commitment  level.     •  •    .  -  :  ,■: 

The  full  service  support  level. 

The  leading-edge  support  level.  _  ■■        .  ;v 

•  It  is  usually  advisable  to  implement  one  service  level  prior  to  the  succeeding 
one. 

•  The  foundation  level  represents  the  best  price/performance  level  for  most 
companies.  This  level  requires  a  minima!  amount  of  IS  resource.  Consulting 
services  is  the  primary  component  of  this  level,  and  it  establishes  the  frame- 
work for  controlling  PC  software  support. 

•  The  leading  edge  can  be  the  riskiest  approach  but  can  also  provide  the  highest 
reward.  In  this  support  level,  IS  will  design  and  implement  a  comprehensive 
set  of  PC  applications.  The  main  risk  is  that  IS  will  not  produce  the  right 
system  or  that  users  may  not  accept  it.  The  reward  is  a  comprehensive, 
efficient  use  of  PCs  throughout  an  organization. 
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DETERMINING  THE  LEVEL  OF  RESOURCE:  AN  ART  OR  A  SCIENCE? 


•  There  is  no  single  formula  for  determining  PC  software  support  resource 
requirements.  It  is  possible,  however,  to  establish  the  order  of  magnitude 
within  the  problem.  The  major  elements  are  related  to  user  characteristics 
(i.e.,  the  number  of  people  who  are  direct  hands-on  PC  users).  More  resources 
are  required  for  a  start-up  operation  as  opposed  to  the  "steady-state"  of  an 
already  existing  operation.  Certain  types  of  users,  such  as  scientists,  engi- 
neers, and  frequent  PC  users,  require  less  support.  ' 

•  Other  factors  affecting  the  intensity  of  support  demands  are: 

Ultimate  recipient  of  output  (user  as  president). 
Source  of  data. 

Quality  of  software  selection  process. 
Software  source. 
Extent  of  multivendor  sources. 
Extent  of  user  training. 

•  Taking  all  the  above  factors  into  account  and  using  timesharing  companies' 
support  ratios  as  a  guide,  the  ratio  of  PC  support  staff  to  end  users  will  range 
from  1:50  to  1:300. 
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1^.  SHOULD  BE  THE  PRIMARY  SOURCE  OF  SUPPORT 


•  There  are,  potential iy,  many  different  sources  of  PC  software  support.  A 
separate  PC  support  unit  in  the  IS  department  could  provide  support  for  every 
area.  There  are  many  other  sources  that  also  may  be  considered: 

IS  department  in  general  (no  specialized  group). 

Users. 

Computer  stores. 

Hardware  and  software  vendors. 

PC  software  consultants  (external  consultants). 

Training  specialists  (external  or  internal). 

•  It  is  difficult  to  make  generalized  statements  since  the  availability  and  qual- 
ity of  stores  and  consultants  vary,  based  on: 

Geography. 

PC  hardware/software  environment. 
Application  area. 

®  It  is  possible,  however,  to  categorize  these  sources  as  being  potentially  pri- 
mary or  secondary  assistance  resources. 
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F. 


METHODS  OF  FINANCING  PC  SOFTWARE  SUPPORT 


•  The  key  issue  for  providing  PC  software  support  is  finding  the  financial  re- 
sources. Too  often  inadequate  support  is  spread  among  a  wide  range  of  func- 
tions because  of  improper  financing.  This  kind  of  support  can  be  worse  than 
no  support  at  all. 

•  Many  IS  departments  assume  that  PC  software  support  must  be  the  same  as  a 
mainframe-based  system;  support  is  provided  by  in-house  IS  staff  and  is  part 
of  the  overhead  cost. 

•  Abdicating  responsibility  for  support  to  the  user  will  not  solve  the  problem. 
The  user  is  usually  ill-equipped  to  support  PC  software.  There  are,  however, 
other  alternatives  for  financing  support;  these  include: 

Charging  back  support  costs  to  users,  either  involuntarily  or  volun- 
tarily. 

"Bundled"  services,  where  IS  leases  hardware,  software,  and  support 
services  to  internal  users. 

Charging  fees  for  individual  support  services. 
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